An idea on multithreading implementation

[Peter Haworth]

I'll admit that I've never had the need to do this with LC but it feels like it should be possible.  How about this.

Make your "Accounts Receivable" a separate standalone LC application and start it up from your main application when it starts up. 

The AR program would have an appleEvent handler in it looking for messages sent to it with a "send to program" command from your main App and use the request appleEvent command to get whatever data you send to it.  Or your main app could put the data in some place accessible to both programs, perhaps an SQL table of pending requests.  

On receipt of the appleEvent, the AR program would do it's thing and send an AppleEvent back to your main program when it's done or report progress back at regular intervals, whatever you need it to do. 

When it's done, it would sit there waiting for another appleEvent to tell it what to do next.   

There don't seem to be equivalents to send to program and appleEvent for Windows but I'll bet some of the smart people on this list can suggest something (and perhaps a better way of doing it on a Mac)

I'm sure this is an over-simplistic description but it seems like it oughta work?

Pete Haworth

On Jan 31, 2011, at 9:56 AM, Bob Sneidar wrote:

> When I started this whole thread, what I had in mind was a simple method for allowing commands and even whole stacks to run concurrently with other stacks, while still being able to communicate with each other through the engine. All the stuff about enabling and disabling communications between things is to me irrelevant. Just compile 2 apps and they will not be able to talk natively to each other. Done deal. 
> 
> Some tell me that multithreading is not that simple. Well nothing under the hood of any app is simple, and triply so for a development environment. My idea was for the engine to handle communications between all of it's objects the way it does now, but have concurrent processes IF YOU WANTED. 
> 
> By default, I envision LiveCode working just the way it does now, with the OPTION to say something like: 
> 
> open stack "Accounts Receivable" with new thread
> or 
> do ReportGen with new thread
> 
> I could then check in on the state of a global from time to time in my Progress Bar modal stack or switch back to my "Order Entry" stack and continue entering my customer's order while the report generator was running. See? I personally do not have any interest whatsoever managing all the threading myself. I use LiveCode so I do not HAVE to know or understand that sort of thing. I am only one person. One of the things that LiveCode allows us to do, which is not talked about much, is to produce really nice and functional applications with incredibly minimal resources (like only one developer!)
> 
> Bob
> 
> 
> On Jan 31, 2011, at 9:35 AM, form wrote:
> 
>> Even discounting games, I'd love to be able to designate a substack to being
>> "threaded", disabling its access to objects in other stacks, and limiting
>> communication to event/message passing.
>> 
>> It would be very much like using the open process command with a Windows
>> command line program. (WHY doesn't it work with Mac command line
>> programs?!?!)
>> 
>> I use open process is a stack to start a makefile and monitor its output
>> while keeping the interface perfectly responsive. I do the same on a mac
>> using a shell command outputting to a text file that I sample the tail from
>> in another shell command. Hackier, but it gets the basic job done.
>> 
>> But if I have LiveCode that I want to start and monitor, I'm out of luck.
>> (Without getting REALLY hacky, that is.)
>> 
>> ~ Chris Innanen
>> ~ Nonsanity
>> 
>> 
>> On Mon, Jan 31, 2011 at 11:57 AM, Bob Sneidar <bobs at twft.com> wrote:
>> 
>>> Well now that there is Livecode for iApps, a lot of people may want it, but
>>> I for one am never going to develop a game, even a simple one.
>>> 
>>> Bob
>>> 
>>> 
>>> On Jan 29, 2011, at 5:06 PM, Alejandro Tejada wrote:
>>> 
>>>> Hi All,
>>>> 
>>>> It's nice to read discussions about features that
>>>> enhance this platform, but now I have one doubt:
>>>> 
>>>> How many developers (who use Livecode) want
>>>> to see this platform converted in a game engine?
>>>> 
>>>> Notice that the only DLL in my wish list for this
>>>> platform is a SWF player, that allows to run
>>>> movies inside a stack, just like the Quicktime
>>>> externals. I do not want to see a Timeline
>>>> in this platform...
>>>> 
>>>> At least in my mind, you could not build (easily)
>>>> the kind of applications created with Livecode
>>>> if it were a game engine. Am I wrong?
>>>> 
>>>> Or There are no boundaries anymore among
>>>> Software Development tools?
>>>> 
>>>> Al
>>>> 
>>>> _______________________________________________
>>>> use-livecode mailing list
>>>> use-livecode at lists.runrev.com
>>>> Please visit this url to subscribe, unsubscribe and manage your
>>> subscription preferences:
>>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>> 
>>> 
>>> _______________________________________________
>>> use-livecode mailing list
>>> use-livecode at lists.runrev.com
>>> Please visit this url to subscribe, unsubscribe and manage your
>>> subscription preferences:
>>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>> 
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
> 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>