Page 1 of 1
can one library stack use the handlers of another one?
Posted: Wed Jun 18, 2008 5:57 pm
by rozek
Hello!
I'm currently setting up a list of library stacks for my further development with RR. My question is:
Can one library stack use the functions of another one? Does that other library stack have to be "started using" later then?
Example: I have a very basic library stack which I would like to use almost everywhere, both in "normal" stacks as well as in library stacks. The situation therefore is as follows:
- the "normal" stack X "starts using" library stack A
- then the "normal" stack X "starts using" library stack B
- library stack B also needs library stack A and therefore "starts using" it as well
Will stack B be able to use the handlers from library stack A which has already been "started using" before? Have all stacks their own "message path" and are therefore independent of other stacks?
Thanks in advance for any explanation!
Posted: Wed Jun 18, 2008 6:00 pm
by Mark
Hi Andreas,
Sure you can. Have you tried it?
Best,
Mark
Re: can one library stack use the handlers of another one?
Posted: Wed Jun 18, 2008 7:37 pm
by Klaus
Hi Andreas,
rozek wrote:Hello!
...
- the "normal" stack X "starts using" library stack A
- then the "normal" stack X "starts using" library stack B
- library stack B also needs library stack A and therefore "starts using" it as well...
the last step is not necessary!
Once a stack is "in use" all its handlers/functions are available to ALL other stacks! And all controls/cards etc. of course!
Best
Klaus
Posted: Wed Jun 18, 2008 8:49 pm
by rozek
Hello,
thanks for your explanations!
Klaus: in this specific case, it might not be necessary, but in general, it is - because stack B does not know that/if stack A has already been registered as a library stack (unless it explicitly looks into the "StacksInUse")
Mark: as mentioned, I face the problem that (at least) one of the public handlers of a library stack is not visible within a "normal" stack - although the library stack is listed in the "StacksInUse" - very strange.
It seems that I'll have to continue investigating the situation...
Posted: Wed Jun 18, 2008 8:52 pm
by rozek
Hmmm,
by the way: what happens, if two (or more) library stacks "export" the same handler (and all handlers "pass" the invocation rather than to trap it) In what order will the handlers be invoked? In the initial order of their corresponding "start using" commands? In the same order as they are listed in "the StacksInUse"?
Posted: Wed Jun 18, 2008 9:00 pm
by Mark
Hi Andreas,
I think that lirbaries are put in a queue after another. The handler in the first library will be executed before the handler in the second library. To test this, make a handler like this:
Code: Select all
on foo
put the short name of this stack & cr after msg
pass foo
end foo
and put this handler into the script of each library. The message box will show in which order the handlers are executed.
Best,
Mark
Posted: Wed Jun 18, 2008 9:41 pm
by FourthWorld
This article may also be helpful:
Extending the Runtime Revolution Message Path
An introduction to using Libraries, FrontScripts, and BackScripts
in Runtime Revolution's Transcript Programming Language
http://www.fourthworld.com/embassy/arti ... _path.html
Posted: Thu Jun 19, 2008 5:50 am
by rozek
Good morning!
Thanks for your hints - I think, the situation is getting a little clearer now (although it's still weird):
It seems, as if every message which reaches the RR engine and which is not explicitly handled there, causes a "can't find handler" error after "start using" one or multiple library stacks...
What did I do:
- I wrote a "libStack" with an "inspectCallChain" command only:
Code: Select all
on inspectCallChain
if (msg is not empty) then put " -> " after msg
put (the short name of this stack) after msg
pass inspectCallChain
end inspectCallChain
- then I wrote a "libStackTest" with the following handler
Code: Select all
on OpenStack
start using stack "libStack"
put (the short name of this stack) into msg
inspectCallChain
end OpenStack
If I now open the "libStackTest", the abovementioned error occurs. While one could understand the reason, why the error occurs, the more important question is:
How can one avoid that error in situations like the above, where a handler should "pass" an invocation, because there
might be another stack which should get the event as well...?
Posted: Thu Jun 19, 2008 5:56 am
by rozek
Ok,
I found the answer myself, just modify the invocation of the affected handler as follows (shown here for the "libStackTest"):
Code: Select all
on OpenStack
start using stack "libStack"
put (the short name of this stack) into msg
try
inspectCallChain
catch Signal
# nop - just ignore the error
end try
end OpenStack
This will also ignore any other errors, but that's a different issue...
Posted: Thu Jun 19, 2008 6:01 am
by rozek
Ok,
and here is the updated code:
- in "libStackTest":
Code: Select all
on OpenStack
start using stack "libStack"
put (the short name of me) into msg
try
inspectCallChain
catch Signal -- just ignore "handler not found" errors
if not(Signal begins with "573,") then throw Signal
end try
end OpenStack
- in "libStack":
Code: Select all
on inspectCallChain
if (msg is not empty) then put " -> " after msg
put (the short name of me) after msg
pass inspectCallChain
end inspectCallChain
This code works as expected (well, for me, at least)
Thanks for alll your input!
Posted: Thu Jun 19, 2008 7:46 am
by Mark
Hi Andreas,
Why do you have handlers with the same name in different library stacks?
Mark
Posted: Thu Jun 19, 2008 7:55 am
by rozek
Mark,
well, if you "start using" foreign stacks, it might happen, that two (or more) stacks provide handlers with the same name.
If you do this by purpose (e.g., because you want to overwrite one handler by another one) then you need to know the order in which these library stacks are searched.
If this happens by accident, then you might have some bad time debugging your code.
RR foresees the presence of handlers with the same name in multiple stack (as one might "pass" the invocation to the next stack) and therefore cannot help out of the situation...
Posted: Thu Jun 19, 2008 8:02 am
by Mark
Hi Andreas,
The main reason for having a pass command is to allow you to handle system messages in different places. Surely, it also allows you to have more than one custom handler with the same name, but this is not recommendable.
When you use a library, you should check its documentation and see if there are any duplicate handlers. Normally, the author of a library would make sure that his or her handler names are pretty unique, e.g. by adding a prefix to each handler.
If you detect problems, you can always tell the author of the library about it and ask for an update.
Best,
Mark
Posted: Thu Jun 19, 2008 8:29 am
by rozek
By the way,
it seems that "the StacksInUse" list the library stacks in the order of their position in the message path - the "inspectCallChain" method lists them in the same order, at least.