Problem solved : no need to care about the global vars declarations (unchanged). My problem was lying in the fact that LC-Server stacks libs statements needs to be addressed as functions or commands and that direct statements alike :
<?lc if then else are only allowed inside flat .lc scripts. Best, Pierre Le 1 août 2011 à 20:20, Pierre Sahores a écrit : > Hi Friends, > > Is there some special precautions to take in about global variables > management and share between lc flat scripts and the stacks libs referenced > on top of the lc script ? > > My habit is to declare all my global vars on top of both the lc scripts > (witch works fine) : > >> global var1,var2,etc... >> >> function onef params >> ... >> end onef >> >> function twof >> ... >> end twof >> >> command onec >> ... >> end onec >> > > and in the stack script (lib) > > witch don't seems to be seen by the lc script after i include > >> start using stack <path to stack> > > > while the stack is clearly well seen by the script (functions no using vars > are well executed by the lc script) > > Where am i wrong and what means that the globals are not dynamically viewable > in between the lc scripts and stack-lib.livecode library ? > > Thanks for any help. > > I hope not to have to declare each global used by the stack lib below each > function / command declaration alike this > >> function onef >> global var1 >> ... >> end onef > > > Kind regards, > > Pierre > > > Le 1 août 2011 à 19:30, J. Landman Gay a écrit : > >> On 8/1/11 10:40 AM, Robert Mann wrote: >> >>> This is the very simple test I made :: made a simple "teststack.livecode" in >>> the IDE : it contains 3 cards and 3 fields, and a few test functions. >>> Dropped it in a test folder on my on-rev account, and added an index.lc file >>> at the same level. >>> >>> problems :: >>> >>> 1) go stack DOES NOT work >>> >>> 2) start using stack, seems to swallow all handlers from stackTest into the >>> HOME stack, so that they loose all the context of their original stack. >>> >>> 3) fields on cards can be accessed IF THE name of the stack is precised each >>> time. >>> >>> So that requires to write handlers in a different way, a standard stack >>> will break very easily on the server if an implicit ref. to a field is used. >>> >>> Any comment? Do I get it right? does "go stack work for some? >> >> These things have always been true of all server-related syntax, including >> the old CGI method. "Go" is a GUI command, and includes an instruction to >> redraw a card. The server has no GUI, so a redraw throws an error. Instead >> of "go", just reference the card remotely. >> >> Long object names have also always always been required for all server work. >> The rule of thumb is to always use long object names, never try to navigate >> within a stack, and always use remote references: >> >> go card 1 -- fails >> go stack "testStack" -- fails >> get the text of field 1 of card 1 of stack "testStack" -- works >> >> The "start using" command has also always been required. It is the only way >> to implement a library script on a server. >> >> I don't think there is a Home stack on a server; there are only libraries >> that sit behind the web page in the hierarchy. >> >> From my old CGI tutorial >> <http://www.hyperactivesw.com/cgitutorial/scripts1.html#trouble>: >> >> <quote> >> Some native Revolution commands that don't work (and may hang your script) >> are: >> >> go - requires a GUI window redraw >> toplevel - GUI-based >> modeless (or any other stack modes) - GUI-based >> create stack (or any file creation) - CGI permissions restriction >> save stack (errors with "can't open stack backup file") - permissions >> restriction >> beep - GUI-based >> </quote> >> >> I haven't worked with the new server yet, but since the current directory on >> the server is outside the CGI-bin folder, creating new stacks and files >> would be possible, unlike the old CGI method in the tutorial. >> >> -- >> Jacqueline Landman Gay | jac...@hyperactivesw.com >> HyperActive Software | http://www.hyperactivesw.com >> >> _______________________________________________ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your subscription >> preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode >> > > -- > Pierre Sahores > mobile : (33) 6 03 95 77 70 > > www.woooooooords.com > www.sahores-conseil.com > > > > > -- Pierre Sahores mobile : (33) 6 03 95 77 70 www.woooooooords.com www.sahores-conseil.com _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
