Hi,
i made an external, call it EXT.
in the main stack, i have a field F, which is filled by EXT.
so far, so good.
Then, i would like to start EXT by using a stack wrapper EXT.rev,
so, the user can start EXT by writing :
start using "EXT"
ok, this work too.
but, then the extenal EXT loose the focus where the field F is
( in the main stack ).
is there a way to manage this in a simple an elegant way without changing
anything in the external ?
regards,
thierry
mainstack -> externalWraperStack -> external
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
Thanks Mark for the reply,
After some more test, it appears to be than
in the libraryStack handler ( and the releaseStack ),
the target is the library stack;
and in all other handlers, the target is the main stack or
a control from the main stack.
That's why i loose the visibility of the main fields, as i start in
the LibraryStack handler, the init() of my external.
I guess i have to find another solution, as i don't see any
clue to know which stack send the "start using "MyWrapperEXT"...
Does someone had encounter this pitfall before ?
Regards,
thierry
After some more test, it appears to be than
in the libraryStack handler ( and the releaseStack ),
the target is the library stack;
and in all other handlers, the target is the main stack or
a control from the main stack.
That's why i loose the visibility of the main fields, as i start in
the LibraryStack handler, the init() of my external.
I guess i have to find another solution, as i don't see any
clue to know which stack send the "start using "MyWrapperEXT"...
Does someone had encounter this pitfall before ?
Regards,
thierry
Hi Thierry,
Since you're making a library, the target can always be different, sometimes a field, sometimes a button. So, the library is not the right place to set the focus.
Instead, set the focus in the same handler that starts using the library:
Best,
Mark
Since you're making a library, the target can always be different, sometimes a field, sometimes a button. So, the library is not the right place to set the focus.
Instead, set the focus in the same handler that starts using the library:
Code: Select all
on someStartUsingHandler
start using stack "EXT"
focus on fld "F"
end someStartUsingHandler
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
The book "Programming LiveCode for the Real Beginner"! Get it here! http://tinyurl.com/book-livecode
Hi,
Ok Mark, i understand this, but probably i made a mistake here talking
of the "focus" ?
i meant the visibility of the user's objects,
of the card or the stack which is going to use the external.
in the process of initializing my external,
i was trying to put all the init stuff inside the library,
and i have to set up few pointers to revolution's objects
( hmmmm, name of objects if you prefer ).
this works well when i use the external straight with my main stack.
Roughly, the external check every parameters and
accept the init() phase as long as the objects are really
part of the user's context stack.
After that, i don't bother at all with this,
and for high troughput functions
i don't check anything, but use intensively these rev's objects.
I was looking for something even more simple, that's why i'm trying to
wrap the external,
so to hide all little boring and delicate initialization
to the developer of the main stack....
so doing: start using "MyCoffeMachine"
is a very elegant way for starting everything, and especially a coffe
With the library, we can easily manage and hide the errors from the external,
which is not that trivial
( see the email of Trevor from this afternoon about
externals in the revolution-mailing-list ).
By now, i only see this alternative:
to do a 2 pass initialization, as:
start using "MyCoffeMachine"
EXT_Init( aDoubleCup, ..., noSugar)
and receive an error from the external,
ie: "Hey, man, not plugged !"
it's the first time i'm dwelling with writing libraries
By the way, making a plug-in, i guess i will pass trough the
same problems, no/yes ?
Hope my english is understandable too
And thanks for your time, i really appreciate.
Regards,
thierry
Ok Mark, i understand this, but probably i made a mistake here talking
of the "focus" ?
i meant the visibility of the user's objects,
of the card or the stack which is going to use the external.
in the process of initializing my external,
i was trying to put all the init stuff inside the library,
and i have to set up few pointers to revolution's objects
( hmmmm, name of objects if you prefer ).
this works well when i use the external straight with my main stack.
Roughly, the external check every parameters and
accept the init() phase as long as the objects are really
part of the user's context stack.
After that, i don't bother at all with this,
and for high troughput functions
i don't check anything, but use intensively these rev's objects.
I was looking for something even more simple, that's why i'm trying to
wrap the external,
so to hide all little boring and delicate initialization
to the developer of the main stack....
so doing: start using "MyCoffeMachine"
is a very elegant way for starting everything, and especially a coffe
With the library, we can easily manage and hide the errors from the external,
which is not that trivial
( see the email of Trevor from this afternoon about
externals in the revolution-mailing-list ).
By now, i only see this alternative:
to do a 2 pass initialization, as:
start using "MyCoffeMachine"
EXT_Init( aDoubleCup, ..., noSugar)
and receive an error from the external,
ie: "Hey, man, not plugged !"
it's the first time i'm dwelling with writing libraries
By the way, making a plug-in, i guess i will pass trough the
same problems, no/yes ?
Hope my english is understandable too
And thanks for your time, i really appreciate.
Regards,
thierry