Standalone Messaging

LiveCode is the premier environment for creating multi-platform solutions for all major operating systems - Windows, Mac OS X, Linux, the Web, Server environments and Mobile platforms. Brand new to LiveCode? Welcome!

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller

Post Reply
WaltBrown
Posts: 466
Joined: Mon May 11, 2009 9:12 pm

Standalone Messaging

Post by WaltBrown » Mon Oct 11, 2010 7:05 am

Another couple of dumb questions - I thought I had seen the answer to this before but now cannot find it.

Is there an LC mechanism for a standalone stack to communicate with non-standalone stacks?

Or alternatively, is there an event available in a non-standalone stack if some other process writes to it? This is in Windows.

Thanks!
Walt
Walt Brown
Omnis traductor traditor

Mark
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 5150
Joined: Thu Feb 23, 2006 9:24 pm
Contact:

Re: Standalone Messaging

Post by Mark » Mon Oct 11, 2010 9:55 pm

Walt,

A standalone can contain a script to open a stack :-)
What exactly are you looking for?

Mark
The biggest LiveCode group on Facebook: https://www.facebook.com/groups/livecode.developers
The book "Programming LiveCode for the Real Beginner"! Get it here! http://tinyurl.com/book-livecode

WaltBrown
Posts: 466
Joined: Mon May 11, 2009 9:12 pm

Re: Standalone Messaging

Post by WaltBrown » Tue Oct 12, 2010 5:16 am

Hi Mark. I have made a very small standalone that is called by a small JS routine (t_ag m_angled) behind a context menu entry in Internet Explorer:

Code: Select all

{    scrip_t language="Java_Script" defer }
var win = external.menuArguments;
var doc = win.document;
var uSel = "\u0022"+doc.selection.createRange().text+"\u0022"+" ";
var uAddr = doc.URL+" ";

uProg="C:ContextMenu\\idCapture.exe ";
WSH=new ActiveXObject("WScript.Shell");
WSH.run(uProg+uSel+uAddr);

{  /scrip_t  }
The standalone is the idCapture.exe. I also have other small standalones behind other apps I use, like Outlook, that perform similar functions.

The idCapture executables all send the data collected to a central dispatcher, which is not at this point a standalone - it has not gelled enough yet. The dispatcher has dynamic sets of rules for what to do based on the source and content of the capture messages. It's primary inbound duty is to decide how to parse and where to store the information based on my current research priorities. It will be running all the time, so I was looking for a "slimmer" way to do this.

As an aside, the various projects I am working on, while having almost no conceptual overlap, still all require the same kinds of back end intelligence architecture and have some amount of source material overlap. I don't have the bandwidth to look at all the blogs, tweets, feeds, and listservs I need to, so I am building this out of self defense.

Today I got a socket architecture going that seems to work, using UDP for initial wakeups and general announcements, then TCP sockets for the dispatcher to publish to registered subscribers (my desktop clients). I didn't want everyone awake at once, so the dispatcher wakes them up as needed using normal LC commands.

The only thing the standalone does is this:

Code: Select all

on preOpenStack 
   local tAddress, tMessage,
   set the destroyStack of this stack to true
   if the long name of me contains ".exe" then
      put "WebCapture" & "::" & $1 & "::" & $2 into tMessage -- the uSel and uAddr in the JS above
      put the hostNameToAddress of the hostName into tAddress
      put ":61618" after tAddress -- this seems to be necessary for LC even if not for UDP

      open datagram socket to tAddress
      write tMessage to socket tAddress with message "doneWriting"
   end if
end preOpenStack

on doneWriting
   -- Hmm, do I need to close the socket?
   quit
end doneWriting
It's still a little flakey, and the EXE doesn't always quit, leaving ghost processes around but I'm getting there. I could probably do the UDP stuff in the context menu JS alone, but to a man with a hammer... (I borrowed the JS from http://www.mattkruse.com).

If I get to the point where I have a decent Publish/Subscribe library, I'll share.

Walt
Walt Brown
Omnis traductor traditor

Mark
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 5150
Joined: Thu Feb 23, 2006 9:24 pm
Contact:

Re: Standalone Messaging

Post by Mark » Tue Oct 12, 2010 9:52 am

Hi Walt,

What is your definition of a standalone? When we talk about standalones here, we mean an executable created of a RR/LC stack.

Best regards,

Mark
The biggest LiveCode group on Facebook: https://www.facebook.com/groups/livecode.developers
The book "Programming LiveCode for the Real Beginner"! Get it here! http://tinyurl.com/book-livecode

WaltBrown
Posts: 466
Joined: Mon May 11, 2009 9:12 pm

Re: Standalone Messaging

Post by WaltBrown » Tue Oct 12, 2010 5:59 pm

Yes, that is what I am talking about. My standalone is basically just a catcher for the context menu event. I made it a standalone so I could launch it from the JS independently of LC and catch command line parameters. I played a bit and discovered that I could call a *.rev or *.livecode stack from the shell, but it did not pass in the command line parameters.

A new question - can non-standalone stacks recieve command line parameters? It appears they cannot.

Here's my stack script:

Code: Select all

on preOpenStack
   answer "Got" $0 && "and" && $1 && "and" && $2 && "and" && $3
end preOpenStack
My command lines:

Code: Select all

CmdLineTest.rev "teststring", "anotherstring"
CmdLineTest.rev "teststring" "anotherstring"
CmdLineTest.livecode "teststring", "anotherstring"
CmdLineTest.livecode "teststring" "anotherstring"
If the stack was already open in LC, I got nothing of course, preOpenStack didn't execute.

When the stack was closed but LC was open I got "Got C:/CmdLineTest.rev and and and" - preOpenStack triggered but the command line params were empty. If I launched it with LC closed, LC and the stack opened but I still got empty command line params (I assume in that case LC got the parameters and ignored them - it threw no exceptions). Both extensions gave the same results (I test this because there are some minor differences in the "binaries" saved from LC with the two extensions). Quoting or not quoting the strings or separating with commas made no difference.

"the Params" Property only returned "preOpenStack". I also tested it on the "openStack" message, same results.

Adding a parameter var after preOpenStack (as in "on preOpenStack pParam") only yielded "pParam".

So, returning to the original question, the standalone appears to be required if command line parameters need to be passed into a stack. True? False?

Thanks,
Walt
Walt Brown
Omnis traductor traditor

Mark
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 5150
Joined: Thu Feb 23, 2006 9:24 pm
Contact:

Re: Standalone Messaging

Post by Mark » Wed Oct 13, 2010 9:58 am

Hi Walt,

I need more explanation before I can answer your questions. You are talking about non-standalone stacks. No matter how you look at it, stacks are documents and documents are no executables. You can't execute them from the shell and you can't pass command parameters to them, although on Unix machines it is possible to set up a standalone of RunRev in such a way that it opens and runs scripts or stacks if it gets called from the command line. I don't think you can do this with RR/LC 4 and later though.

Regardless of how you do it, you will always need a standalone to open a stack. To "communicate" with (non-standalone) stacks, these stacks have to be opened by the standalone.

I really don't know why C:\stackname.rev would open a stack and execute any scripts. I don't think this is supposed to happen. The command line should return an error.

I wouldn't even try to issue command parameters to anything but a standalone application. This doesn't only apply to RunRev, it applies to anything. As far as I know, passing parameters to a Wordpad document simply doesn't make any sense! I'm really baffled that entering the name of a RR/LC document doesn't just return an error.

Kind regards,

Mark
The biggest LiveCode group on Facebook: https://www.facebook.com/groups/livecode.developers
The book "Programming LiveCode for the Real Beginner"! Get it here! http://tinyurl.com/book-livecode

WaltBrown
Posts: 466
Joined: Mon May 11, 2009 9:12 pm

Re: Standalone Messaging

Post by WaltBrown » Wed Oct 13, 2010 4:02 pm

Mark,

My standalone is "idCapture.exe". It is the standalone that I use to open a non-standalone. That's what I am doing, using a standalone so I can pass command line parameters into a process that can then issue LC messages to other stacks. This is working successfully.

The later "C:\Stack.rev" lines were me testing to see if I could pass any command line params to a non-standalone, and I found I could not, which is the reason for my question, in case I missed something. You answered it in "I don't think you can do this with RR/LC 4 and later though." Thanks.

And no, issuing a stack name on the command line returns no error because LC is the application registered in Windows to open files with ".rev" and ".livecode" extensions. I could also enter "C:\mydoc.doc" and it would open successfully in Word, "C:\mytext.txt" would open in Notepad++, "C:\mypresentation.ppt" would open in PowerPoint, etc, just like double clicking on the file's icon or directory entry.

BR,
Walt
Walt Brown
Omnis traductor traditor

Janschenkel
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 977
Joined: Sat Apr 08, 2006 7:47 am
Contact:

Re: Standalone Messaging

Post by Janschenkel » Wed Oct 13, 2010 5:05 pm

There's nothing to stop you from checking $0 through $n in a preOpenStack handler in the non-standalone stack. Or you can send these along as a separate message after loading that stack, after filtering out irrelevant parameters.
Also check out the relaunch message in the Dictionary - as this will be sent when the user opens a second instance of your application (for instance, byè double-clicking a document with an extension associated to your application. Finally, you can use a different extension for your application stacks - preferably something that is pretty unique yet is easy for the user to make the mental connection to your application.

HTH,

Jan Schenkel.
Quartam Reports & PDF Library for LiveCode
www.quartam.com

Mark
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 5150
Joined: Thu Feb 23, 2006 9:24 pm
Contact:

Re: Standalone Messaging

Post by Mark » Wed Oct 13, 2010 5:21 pm

Hi Walt,

Since you're on Windows rather than Unix, you won't be able to treat a stack as an executable anyway. Older Rev stacks contain a reference to a standalone and the Unix command line uses the referred standalone to execute the script or stack, very much the same way CGI scripts work. This seems irrelevant, since you're on Windows.

I just did a few tests. Command line parameters can only be passed on to a standalone and not to a document.

Why is this that important? What do you care about specifying the standalone?

Have you conisdered setting up a standalone as a server? You could make an http server running on a different port and let it act whenever a particular URL is requested. These URL's can even contain a reference to a stack. This saves you from having to start the standalone every time you want to execute a little script. Such a server can be made with Revolution.

The relaunch message, suggested by Jan, involves starting another standalone, before it hands over the execution of the shell command to the first, already running standalone. This doesn't seem very efficient to me.

Kind regards,

Mark
The biggest LiveCode group on Facebook: https://www.facebook.com/groups/livecode.developers
The book "Programming LiveCode for the Real Beginner"! Get it here! http://tinyurl.com/book-livecode

WaltBrown
Posts: 466
Joined: Mon May 11, 2009 9:12 pm

Re: Standalone Messaging

Post by WaltBrown » Thu Oct 14, 2010 5:09 am

Thanks Mark and Jan.

I'll check out making an HTML server if I decide to polish it.

Walt
Walt Brown
Omnis traductor traditor

Post Reply