can one library stack use the handlers of another one?

[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!

[Mark]

Hi Andreas,

Sure you can. Have you tried it?

Best,

Mark

[Klaus]

Hi Andreas,

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

[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...

[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"?

[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

[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

[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...?

[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...

[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!

[Mark]

Hi Andreas,

Why do you have handlers with the same name in different library stacks?

Mark

[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...

[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

[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.