[server] using STACKS within ON-REV

[Pierre Sahores]

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         |     jacque at hyperactivesw.com
>> HyperActive Software           |     http://www.hyperactivesw.com
>> 
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at 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