Studio Programming Conventions and Editing Tips

[tmiranda]

Looking through the code from the default STV I see that the convention seems to be to always put widgets that are executed sequentially as children rather than as "siblings". For example, if there are three action widgets that are to be executed sequentially they are coded in studio as:

Widget 1
  Widget 2
    Widget 3

Rather than:

  Widget 1
  Widget 2
  Widget 3

Where the indented widgets are children widgets. Why? This seems to create a lot of clutter and difficulty in editing (see my next question). Don't the two example below do the same thing?

Example 1:

If Expression
true
  Widget 1
    Widget 2
      Widget 3
else
  Widget 4

Example 2:

If Expression
true
  Widget 1
  Widget 2
  Widget 3
else
  Widget 4

Why code things like example 1 when example 2 seems to be a lot "cleaner" and clearer (to me at least)?

Next, how do you most effectively add or delete widgets that are somewhere in the middle of one of these long chains of children widgets? For example, what is the easiest way to delete Widget 1 in example 1? The manual says not to delete a widget if it has children but rather delete from the "bottom" and work your way up. What I've been doing is "collapsing" the chain at Widget 2, selecting Widget 2, cutting and pasting it just after the "true" and then deleting Widget 1. Is this the best way to do things?

Likewise, what is the easist way to add a Widget that needs to be placed before Widget 1? If I add a Widget after the "true" it becomes a "sibling" of Widget 1. What I have been doing is collapsing the chain at Widget 1 and then cutting and pasting it as a child of the newly inserted Widget. Is this the best way?

Thanks,

Tom

[Fuzzy]

It is just the way they implemented the system. It is unconventional, but works well for handling parallel tasks, as instead of a single execution point in the entire STV, it can fork to different processes, and those can run down their individual 'family tree' if you will.

[tmiranda]

I'm not sure what you mean. Are you saying that it's done this way so at another point in the STV I can put a reference to a widget and effectively use that widget chain as a "subroutine"? How does this help when using parallel tasks via fork()?

The developers at Sage have obviously coded the STV this way on purpose and I want to know what that purpose is so I can get a better grasp of Studio programming. They certainly know a lot more about Studio than I do and I want to learn from their experience.

Tom

[PLUCKYHD]

You can code either way. I only use the tree effect if I am calling some menu or if statments after evaluation.

[Opus4]

Originally Posted by tmiranda

Don't the two example below do the same thing?

Example 1:

If Expression
true
  Widget 1
    Widget 2
      Widget 3
else
  Widget 4

Example 2:

If Expression
true
  Widget 1
  Widget 2
  Widget 3
else
  Widget 4

Why code things like example 1 when example 2 seems to be a lot "cleaner" and clearer (to me at least)?

It depends on what the code is for; those examples may do the same thing, they may not. Have you read through the section of the Studio manual called "The Widget", starting around p. 13? If the above code is for a Process chain, they should accomplish the same thing. If the code is part of a UI chain, they will not.

BTW: your example 2 can get quite large & harder to collapse portions of it if you have many more widgets all placed as siblings.

Next, how do you most effectively add or delete widgets that are somewhere in the middle of one of these long chains of children widgets? For example, what is the easiest way to delete Widget 1 in example 1? The manual says not to delete a widget if it has children but rather delete from the "bottom" and work your way up. What I've been doing is "collapsing" the chain at Widget 2, selecting Widget 2, cutting and pasting it just after the "true" and then deleting Widget 1. Is this the best way to do things?

Yes, you would move the children & deleted the now-childless widget...

Likewise, what is the easist way to add a Widget that needs to be placed before Widget 1? If I add a Widget after the "true" it becomes a "sibling" of Widget 1. What I have been doing is collapsing the chain at Widget 1 and then cutting and pasting it as a child of the newly inserted Widget. Is this the best way?

Yes -- add the new widget, then move the other widget chain(s) to be its children.

Moving can be done easier with the mouse, in my opinion -- see "Moving and Copying Widgets" around p. 75.

But... for more widget manipulation tools, I suggest you check out GKusnick's Studio plugin:
New tools for Studio users

- Andy

[tmiranda]

Thanks Plucky and Andy.

I am talking about a process chain, not a UI chain.

I have installed GKusnick's tools, but so far I've only been using a few of its capabilities. (Searching mostly.) Time to read some more ....

Tom

[PLUCKYHD]

andy I got a question related


Say you are setting values for attributed in let's say a focus gained hook an you have

If value
True
Attribute = true
False
Attribute = false
Attribute 2 = true
Attribute 3 = true

Can you just call refresh for the area at the botto. If they are all in the same refresh area or do you have to call it after each attribute and chain of commands?

If I have a longer chain of code then above will it get executed fully before the refresh

[jaminben]

Originally Posted by PLUCKYHD

andy I got a question related


Say you are setting values for attributed in let's say a focus gained hook an you have

If value
True
Attribute = true
False
Attribute = false
Attribute 2 = true
Attribute 3 = true

Can you just call refresh for the area at the botto. If they are all in the same refresh area or do you have to call it after each attribute and chain of commands?

If I have a longer chain of code then above will it get executed fully before the refresh

I've seen plenty of examples of user code where they place the refresh at the bottom but I don't ever recall seeing regular Sage code do this. I don't know if its right or wrong but it does seem to work just fine located at the bottom.

[Opus4]

Refreshes are fairly slow, as far as code execution goes, since it needs to re-evaluate and redraw everything on the screen. So, they should not be done after every line of code unless you really have a good reason for doing so. And, unless you really need to refresh the entire screen, you should refresh just the affected areas instead.

- Andy

[PLUCKYHD]

Originally Posted by Opus4

Refreshes are fairly slow, as far as code execution goes, since it needs to re-evaluate and redraw everything on the screen. So, they should not be done after every line of code unless you really have a good reason for doing so. And, unless you really need to refresh the entire screen, you should refresh just the affected areas instead.

- Andy

Thanks andy yes I stopped using refresh and starting refeshing areas along time ago but always had a refresharea call after every line or tree of code and wondered if it was necessary