Zugg Software :: View topic

Adept Joined: 27 May 2008 Posts: 299

I was asked by Zugg to move this from here...

http://forums.zuggsoft.com/forums/viewtopic.php?t=31597

The reason this would be handy isnt really for constant changing as once you have it set theres no real reason to change it but to help in setting up scripts.

Currently what I do with my scripts is onLoad I create a persistant Module in the users main package that holds all settings variables, this keeps the user from losing all their settings each time I update the script and they get a new package file.

I do something like this in my onLoad event...

IF @testvar {} {#MODULE ScriptConfig;#VAR //ScriptConfig/testvar %null;#VAR //ScriptConfig/testvar2 %null}

This works great except apon first install the user has to manually go in and change the module ScriptConfig to Global.
What I would propose is possibly a arguement to #MODULE, so you could do #MODULE ScriptConfig Global... Or even %module(ScriptConfig, Global) or something like that.

This is also much needed for the package list that each module is tied to, but I think that would be really hard to do.
One option is to add a command that would automaticly make that module scoped to the Main Package.

Currently you can read the long drawn out process I have to walk my users through so they can add my package (for the first time).

Read Here.... http://davos.aardcharn.com/trackers.html

Thanks for anything that might make this process simpler for the novice user.

Posted: Fri Aug 22, 2008 6:28 pm

I see what you mean about being able to specify the scope at the time of programmatic creation, and I do agree that should be add.

Unless I'm misunderstanding the problem however, you should still be able to access all the variables in that new local package by using the fully qualified variable name. i.e. referencing them as @//ScriptConfig/testvar2

Adept Joined: 27 May 2008 Posts: 299

I believe that unless that module with the vars is scoped properly it creates a new var under your main window with the name //ScriptConfig/testvar2.

I may be wrong tho...

I still dont understand how to use %packages since there is no documentation on the command yet.

Adept Joined: 27 May 2008 Posts: 299

Ok so it looks like what I would do in order to add a specific package to a window is...

Adept Joined: 27 May 2008 Posts: 299

Meh 2 different threads with the same thing in it heh, well anyways... the above code works... So that solves most of my problems, now just if I had a command to change the Global flag.

Also is there a command to pull all the windows/modules in a session?

Or better yet, right now when you add a package to your session it defaults to checked in all your windows in your default package... Can we have it only default to checked for the window with a connection? Its a pain having an alarm you add via adding a package fire 3 times because you have 3 windows by default.

Posted: Fri Aug 22, 2008 8:29 pm

As for directly accessing local variables, check it out. 99.9% sure that's what I'm doing with my own code, for the same reasons you described, and I never changed the module scope. On the other it would still be useful if the end user tried to access it from their own scripts.

Adept Joined: 27 May 2008 Posts: 299

Posted: Fri Aug 22, 2008 9:32 pm

I know what you mean if it's already coded it won't be fun.

However as a point of gaining maximum portability of your scripts, you should probably be doing that anyway. You don't know for sure what other variables the user has defined with those variable names, or for that matter what other packages they may have enabled with the same variable names. If that happens, you're dependent on the scoping rules always coming out in your favor (i.e. the variables you wanted updated). But that's just some feedback, one package developer to another.

Adept Joined: 27 May 2008 Posts: 299

Hmm it might not be too bad... Do all commands that use variables take the //module/class syntax?

For instance...
#PROMPT
var = val

stuff like that?

SubAdmin Joined: 18 Nov 2001 Posts: 5182

One of the things I have to question is why you think a module is needed for this. The general rule is that creating a setting should occur within the window that the script is run from. This rule came from the simple statement (paraphased), 'if a person publishing a package wanted the setting to be contained in that package, then they would have included it there.'

That statement is what lead to the decision that a new setting should be created within the window that is executing the script. By trying to create a module to contain all the settings you want to create you are pushing the edge of the scoping rules. Also a module being created with the scope of local would behave the nearly the same as creating the settings directly within the window. This is something many users spent a fair bit of time considering to determine as the appropiate rule definition.

The only thing I can think of that might be a problem is that the script is compiled before the settings exist and then refuses to recognize them when they have been created during the scripts execution. That would be a bug that needs to be addressed, and should clearly be reported in another topic. I am fairly certain that Zugg still runs the the scoping tests, that were designed into a package for him, each version. Those test include creating settings in configurations like you are concerned about.

Basically I have no idea why you think the module you are creating needs to be global. I also have no idea why you are using a module instead of a class, since a class is considered below a module it is more appropiate for a module to spawn a class.

Adept Joined: 27 May 2008 Posts: 299

Using a module, vs a class under the main session window is a matter of preference honestly and it keeps my settings seperate from everything they may have coded. And apparently they dont NEED to global if I wish to use the full path every time I call that variable... Kinda annoying but it will work and will probably keep alot of other issues from happening like Tech stated.

The reason I dont include the settings WITH the package is fairly obvious and has already been stated. When I upgrade the package with fixes and/or new features I dont want the user to have to lose all their personal setting for that script. So by creating them in a module under their main package this eliminates that.

But I still see the need to be able to change the Global tag via script, regardless. I mean, you can change everything else, why not this?

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Evidently you missed the entire point of my post. The scoping rules cover most inheritance, for example a user makes a variable by the same name within the window and that overrides the one published with a package.

They also specifically cover not publishing a setting with the package, by concluding that that setting must have been meant to be window specific. Your desire to put them in a module instead of a class within the window just means you want your stuff 1, let me be absolutely clear I am saying ONE, level higher. Does that ONE level actually mean something to you? I already made it perfectly clear the scoping rules state that a setting not included within a package should be created within the calling window. What became the specific point for the discussion was(paraphasing again), 'the author of the package would have included that variable if they wanted it there.' This means the scoping rules are already covering your reasons, in fact they were designed with your reasons in mind!

I don't quite see the reasoning behind perfering a module to a class. I really can not find any reason that a Local module would not do what you want if all the scoping rules are working correctly. Can you point out a flaw a rules?

I personally have no problem with your desire to use #MODULE to create a additional module in the main session package instead of dumping things into the window. I just can't quite understand why you feel the need to create a module in someone else's package as a global module, read let's use a name that is going to break a Charneus script, when you only need the window that activated the onLoad to have access to the module. Keep in mind that the scoping rules provide that first anything that window has access to will be used and then anything the script can access(by virtue of its package and module) wil be used. Window typed modules are 'self' only scoping allowing multiple settings of the same name to be used with each window. This is by design and using global modules overrides that.

Wizard Joined: 22 Mar 2007 Posts: 2320

As an aside, not really dealing with the original suggestion, here is what I have done. I, too, wanted to store permanent variables without worrying about them being overwritten by package upgrades. I put my variables in a separate module, in my case under the main session package. But to access the variables, I created a function. By using the function to set and retrieve the variables, I don't have to remember with every new script the full path to the variable. I can even move the variables to a new location, or change things from simple variables to keys in a db variable, or any other change I like, and only have to change the one function instead of every trigger and alias that uses them.

Adept Joined: 27 May 2008 Posts: 299

Ok so after some testing I've come to this conclusion...

When I add a package that uses a module in the main session package these are the settings that need to take place...

1. Main session window must have new package checked (Is by default when you add it)
2. Module that the new package uses must have new package checked (can be done via script)
3. Module(s) inside new package must be marked Global (Setting stays with package, not session, so shouldnt need changing on install)

With this setup, all my scripts SEEM to work, eventho the variables in the new package that are actually in the module in the main session package are red. But it still calls and edits them like it should.

Am I correct in assuming this is all that needs to be done? Sorry this is just hella confusing to me and evetho your well-intentioned Viji, you don't make it any easier to understand, heh.

Posted: Mon Aug 25, 2008 8:21 pm

Sounds about right. But the proof is always in the pudding. Save a version then run with them for a while to see how it works for you.

Adept Joined: 27 May 2008 Posts: 299

Its just weird that using the variables in the new package are red eventho they do get called and edited fine via the script in the new package.

Posted: Mon Aug 25, 2008 9:17 pm

Might be a bug in the syntax highlighter. Show me exactly what syntax your script is using and where the actual variable exists so that I can try to reproduce the problem here.

Adept Joined: 27 May 2008 Posts: 299

Steps to reproduce.

Launch CMUD, hit Esc.
Open Settings
New module in untitled package named test
New variable under test module named test with value of 1
file/new package, name it whatever
new alias in new package with name test and this as the value #IF @test {#say worked}
Under the test module mark the new package in the list.
Go back to the alias in the new package... @test is red.
type test, you get worked.

BTW its colored red in every syntax for that it would normally color a variable blue/red...
%db(@var,key)
@var
etc...

Posted: Mon Aug 25, 2008 9:26 pm

OK, thanks for the steps, I've added that to the bug list.

Posted: Mon Aug 25, 2008 9:46 pm

They are red because they are inaccessible under the default scoping rules... i.e. they won't accidentally be used. They can only be accessed if you explicitly refer to them.

[Edit] I stand corrected.