XYplorer Beta Club

Posted: **17 Feb 2013 15:41**

Why not simply sub "_Initialize"; ?

Posted: **17 Feb 2013 15:48**

PeterH wrote:Why not simply sub "_Initialize"; ?

Yes, FluxTorpedoe may use this standard method in his script, but I will customize for myself. As said, I want to call label externally. [::load Sessionmanager.xys, label] would ignore "_Initialize".
P.S: Dear FluxTorpedoe , the standard method í:

Code: Select all

"_Initialize"
 perm $a, $b;
 $a = Itema;
 $b = Itemb;

"_Terminate"
 unset $a, $b

"Menu1 : Menu1"
 msg $a with $b

Posted: **17 Feb 2013 21:26**

binocular222 wrote:
PeterH wrote:Why not simply sub "_Initialize"; ?
Yes, FluxTorpedoe may use this standard method in his script, but I will customize for myself. As said, I want to call label externally. [::load Sessionmanager.xys, label] would ignore "_Initialize".
P.S: Dear FluxTorpedoe , the standard method í:
Code: Select all
"_Initialize"
 perm $a, $b;
 $a = Itema;
 $b = Itemb;

"_Terminate"
 unset $a, $b

"Menu1 : Menu1"
 msg $a with $b

Sorry, I don't understand

::load "test.xys", "_Initialize"; works without problem, too.

So are we talking about different things?

And to the example you show here: I see no difference between "Menu1 : Menu1" and "Menu1"?

As far as I understand the label part of the caption *can* be used to define a short form of identifying the script, when the label itself is quite long, e.g. for descriptive reasons.
So: "Here we copy this to that and the delete : copydel" can make sense.

Posted: **18 Feb 2013 03:14**

I thought that I have to define a proper label such as [Menu1 : Label1] to call by "::load". Sound that I'm wrong, [::load] can call menu name too! So, the help file is inadequate again. I tested and this works:

Code: Select all

"_Initialize"
 perm $a, $b;
 $a = Itema;
 $b = Itemb;

"_Terminate"
 unset $a, $b

"Menu1"
 msg $a with $b

Then call with [::load test, "_Initialize";load test, Menu1]

Posted: **18 Feb 2013 08:26**

@KindDebuggers
Well thanks for the feedback, that was it indeed: No more than 1 bold menu item under Win7!
So everyone (under Win7) trying SM2 with "Layouts ON" couldn't see the active session... Dang!

As for the options, some of them would disappear too (including the ReduceFlickering status), though the grayed-out ones are normal: Layout options are only available when Layouts are ON (and vice-versa for Standard). I'll post an update soon.

@binocular222 & other Coders
I guess I see what you want, and in the way I discovered something interesting (which may already be obvious to some of you):
• In a script, one can load an external subscript containing global declarations, then use those globals without redeclaring them. (Exactly as it works with internal sub calls.)
e.g. in the case of binocular, who wants to load an external subscript "Menu1", but using vars declared in another subscript "_Initialize" (or any other for that matter!)
Say you have Script1.xys:

Code: Select all

"_Initialize"
  global $a, $b;
  $a = "Itema";
  $b = "Itemb";

"Menu1"
  global $a, $b;
  msg "$a with $b";

And you're calling it from Script2:

Code: Select all

  load "Script1", "_Initialize";
  load "Script1", "Menu1";

And it works! Without Script2 needing the word "global" at all...

PS: In my case with SM2, I don't need perm vars and I'd rather avoid them if possible.

So to sum things up, when I have the time, I shall rewrite (once again!) SM2 code to compartmentalize globals into an "_Initialize", so that its subscripts could be called externally. Too busy right now, but I'll do it...

Posted: **18 Feb 2013 14:17**

Hi PeterH,
Yes, that is unexpected...maybe. Don in the beta discussion said,

If a script within a MSR is called directly (SCs Sub or Load),
then "_Initialize"/"_Terminate" are NOT called.

In this case you have a second MSR file and in it you are loading "_Initialize" from script1 which would which declares the globals and then loading another label in script1 which successfully uses those global variables without declaring them. So I guess we'd have to do more testing to see what happens when load or sub is used withing the same MSR. I would think that globals would have to be declared in another script within the same MSR as we always have, whereas perms would not. What he is referring to in the above quote is directly loading a script (label) within an MSR script as for example in a left/right click definition for a CTB. In this case "_Initialize" would not be loaded automatically. In your case you called "_Initialize" directly before loading another label.

I suppose we're all trying to wrap our heads around all these new changes. They do open up some new scripting possibilities

and the need for tweaking old scripts to clean up the code, don't they?

Thanks,
Ken

Posted: **18 Feb 2013 15:06**

@klownboy
I'm afraid the problem is that you misuse _Initialize a bit?

The logic, if I understood it correct, is quite simple: if you start (by any means) a MSR *without* specifying the name (caption or label) of a script to execute, _Initialize is executed, a selection list is shown, and in the end _Terminate is executed.
If you start the MSR and *do* supply a unique script caption/label, it will be executed *without* all additional support.

So if you have scripts "A" and "B" in an MSR, and these might be started with or without specifying an explicit caption, one time _Initialize is executed, the other time it's not.

The reason is that this new logic is made to help on display of the script-captions in the selection menu. And it's not executed if no selection menu is to be shown.
(This can be interpreted positive and negative

- for me it's OK.)

If you want to execute some general preparation, like define perm variables, you can do so in a hidden routine like "_prepare", and call this on start of any script. This may be embedded in the current MSR, (called by sub,) or even be in separate script, called by load (then it may even not be hidden).

But I think Don still has an error (eye-catcher

) here: you may call a MSR with a list of captions, like Load "script", "A;B"; leading to a selection list showing the captions for "A" and "B". I think in these situations _Initialize should be executed - but it isn't.

Posted: **18 Feb 2013 16:43**

PeterH wrote:But I think Don still has an error (eye-catcher ) here: you may call a MSR with a list of captions, like Load "script", "A;B"; leading to a selection list showing the captions for "A" and "B". I think in these situations _Initialize should be executed - but it isn't.

maybe. maybe not. I tend to the latter.

Posted: **18 Feb 2013 17:08**

admin wrote:
PeterH wrote:But I think Don still has an error (eye-catcher ) here: you may call a MSR with a list of captions, like Load "script", "A;B"; leading to a selection list showing the captions for "A" and "B". I think in these situations _Initialize should be executed - but it isn't.
maybe. maybe not. I tend to the latter.

Sorry - I don't understand.

I think:
- If _Initialize is used to be able to show perm variables resolved when displaying the selectionlist for the script to execute, this should also be done if only a subset of entries is shown.
(This seems to be the only reason for _Initialize to be executed before showing the list, and only if really showing it?)

- But if _Initialize is used to "prepare" for the real script execution, it should be executed always. But this could be done by explicit "sub" or "load" of some (maybe hidden, or external) script.

So did I misunderstand something?

Posted: **18 Feb 2013 17:51**

Hey PeterH

I'm afraid the problem is that you misuse _Initialize a bit?

Well, that may be true, but I made it clear in at least one post that I did not have have to use "_Initialize", but did so simply to test the new capabilities. You know I'm very new to scripting, but in most cases lately, at least since these new functions came out, I was using "perm" in a menu so both perm and "_Initialize" was necessary.

So if you have scripts "A" and "B" in an MSR, and these might be started with or without specifying an explicit caption, one time _Initialize is executed, the other time it's not.

The reason is that this new logic is made to help on display of the script-captions in the selection menu. And it's not executed if no selection menu is to be shown.
(This can be interpreted positive and negative - for me it's OK.)

Have you tested what you're saying? I've ran MLS files both with and without menus and "_Initialize" and "_Terminate" are run in both cases.

If you want to execute some general preparation, like define perm variables, you can do so in a hidden routine like "_prepare", and call this on start of any script. This may be embedded in the current MSR, (called by sub,) or even be in separate script, called by load (then it may even not be hidden).

Yes, I know I've done that, but in my case I wanted to define Perm variables which got displayed. That is "originally" why Don came up "perm" use in this way along "_Initialize." But use of "_Initialize is not limited to that. It will run, if detected, in any MSR file provided one does not load/call out a specific label.

- But if _Initialize is used to "prepare" for the real script execution, it should be executed always. But this could be done by explicit "sub" or "load" of some (maybe hidden, or external) script.

The point is you can now use "_Initialize" and reduce or avoid using sub or load label at least to establish initial conditions. As I said above, I haven't ran into any situations yet where "_Initialize" isn't run (except when calling a specific label), but I'll do more testing.
Thanks,
Ken

Posted: **18 Feb 2013 17:53**

BTW, next version you get a GUI way to unset perms: right from the list in menu Scripting | Permanent Variables.

Posted: **18 Feb 2013 18:24**

Aha, today is obviously my turn to experience the "Hey, I got my wish, without asking for it!"-feeling. Cool.

Posted: **18 Feb 2013 18:27**

"GUI way to unset perms" will actually be quite handy especially now-a-days doing all this playing around or should I say "testing" of perms. Thanks!

Posted: **18 Feb 2013 18:28**

klownboy wrote:"GUI way to unset perms" will actually be quite handy especially now-a-days doing all this playing around or should I say "testing" of perms. Thanks!

Yep, that's why I did it. I needed it myself.

Posted: **18 Feb 2013 19:03**

@Klownboy
What I've tested: the following script, in \test subdirectory of <xyscripts>

Code: Select all

"_Initialize"
 text "Init";

"_Terminate"
 text "Term";

"a"  Text "a";

"b"  Text "b";

"c"  text "c";

"sub" sub "a;c";

When started via Scripting/Load Script File... or via ::load "test\$t"; in AB the scripts _Initialize and _Terminate are executed.
When started via AB ::load "test\$t", "..."; with "..." being "a", "b", "c", or "sub" _Initiate and _Terminate were not executed, and no selection menu shown.
When started via AB ::load "test\$t", "..."; with "..." being "a;b", ..., or even "a;b;c;sub" still no _Initialize or _Terminate, but selection menu shown.

When "sub" is executed, it calls itself, allowing "a" or "c". No _Initialize or _Terminate, but sel menu for a and b.

So all start types supplying one caption (or any list of captions) lead to no-execution of _Initialize or _Terminate.

All tested with version 12.10.0016

To say: my wording "misuse" wasn't meant to be negative in any way - sometimes misuse can lead to very good results. It was meant in the sense of saying "you must be very careful when you do".
But in the moment I'm in the situation that I myself don't understand Don's intention and what they mean to the functionality. Maybe he will explain what I asked for...

Must interrupt now - will have a look in some time...

XYplorer Beta Club

Session Manager [v7.90] — Bookmark your environments: locations and/or display (save/restore tabsets and layout)

Re: Session Manager [v1.02]

Re: Session Manager [v1.02]

Re: Session Manager [v1.02]

Re: Session Manager [v1.02]

Re: Session Manager [v1.02]

Re: Session Manager [v1.02]

Re: Session Manager [v1.02]

Re: Session Manager [v1.02]

Re: Session Manager [v1.02]

Re: Session Manager [v1.02]

Re: Session Manager [v1.02]

Re: Session Manager [v1.02]

Re: Session Manager [v1.02]

Re: Session Manager [v1.02]

Re: Session Manager [v1.02]