Layers protocol…

[Regulae]

Hi there,

It can certainly be difficult to determine if a particular develpment environment has the capabilities a specific project requires, and there's always the worry that some "deal breaker"- some vital requirement that the environment cannot meet- is lurking just around the corner. The fact you are so clear about the "layer" capabilities you require is a good starting point, and perhaps some of the following may help.

Some quick tests, prompted by some of your queries on groups, blendLevels and ID's revealed the following:

There are properties of a group which applies to all its members, e.g. blendLevel changes apply to all controls in a group. You can change the degree of transparency (called blendLevel in LiveCode) of individual controls in a group, and also the blendLevel of the entire group. A control's blendLevel can range from 0 (opaque) to 100 (transparent). A control (e.g. a button) with a blendLevel of 50, if part of a group whose blendLevel is 50, appears on-screen to have a blendLevel of 75 i.e. much of what is underneath the button is visible as it is very transparent.

A control can be added to a group or removed- its ID remains unchanged.

There are several LiveCode terms which are particularly relevant to the current discussion: control, ID, group, layer, and number. I found making a combined summary of the dictionary entries (found in the LiveCode integrated development environment (IDE)) rather helpful, though it may be worth reviewing the actual entries in case my excerpts exclude something crucial to your specific requirements. Mostly it's selective cut-and-paste but I've included some comments in square brackets where it seems useful.
-----------------
Control (synonym: part)
Designates all object types that can be placed on a card. Use the control keyword in an object reference. A control is any object that can be placed on a card: a button, field, scrollbar, image, graphic, player, EPS object, or group. You can refer to a control by number or by name. The expression control 2 refers to the control whose layer is 2. The expression control "this" refers to the first control whose short name is "this".
-----------------
ID
Use an object's ID property to refer to the object in an unambiguous way. [Regulae: after discussing the ID of stacks and images, which are special cases the dictionary continues ...] For all other objects, the ID property is assigned when the object is created and never changes. This means that for all objects except stacks and images, the ID property is guaranteed to be persistent. An object's name or number may change, but its ID does not.

For all objects, the ID is guaranteed to be unique within a stack. IDs are not reused if the object is deleted.

Note: An object that is created by copying and pasting, or with the copy command, is assigned a new ID. If you cut an object and paste it into the same stack, it retains its original ID.
-----------------
Group (synonyms: grp, background, bkgnd, bg)
A control that contains other controls. Use the group object type to hold sets of controls, radio-button clusters, menu bars, and controls to be displayed on more than one card. [Regulae: you can also have the group on just one card only, and indeed multiple groups on the one card. Groups have a number of settable properties, like blendLevel mentioned above. If the group's backgroundBehavior property is set to true (either by script, or by opening its Property Inspector in the IDE) it can be placed on more than one card i.e. it acts as a background. As a background, (for example) if you change the position of a control in the group, the change is seen on all the cards sharing the background. You can have multiple groups acting as backgrounds, on multiple cards, which is a versatile feature. A groups can have custom properties, distinct from the custom properties of the controls it contains.] A group is a set of controls that has been made into a single control. You can select, move, resize, or copy the group, and all the controls in it come with the group. You can show a border around the group (using its border property), a label (using the showName property), or scrollbars.

Groups can contain any type of control (including other nested groups).
[Regulae: Naturally, being able to easily refer to specific controls in a group is important. If we have a field "two" in group "multiple", the long name of the field is:

Code: Select all

field "two" of group "multiple" of card id 1002 of stack "C:/Program Files/Revolution Studio/LayerTest.rev"

... and its long ID is:

Code: Select all

field id 1013 of group id 1018 of card id 1002 of stack "C:/Program Files/Revolution Studio/LayerTest.rev"

... as an example, from my test stack, of how you can refer to specific controls in groups. If you include group "multiple" in a larger group "BigGroup", you can refer to it using e.g. its long name:

Code: Select all

field "two" of group "multiple" of group "BigGroup" of card id 1002 of stack "C:/Program Files/Revolution Studio/LayerTest.rev"

You could also use its long ID.]

When referring to a group using the synonyms background, bkgnd, or bg, the reference is to one among the groups in a stack, rather than to one among the groups on a card. For example, the object reference background 1 indicates the first group in the current stack, not the lowest-layered group on the current card.

The group object has a number of properties and messages associated with it. To see a list of messages that can be sent to a group as a result of user actions or internal Revolution events, open the "Revolution Language Dictionary" page of the main Documentation window, ensure that the group column is visible and use sort and filter to bring the relevant entries to the top. {Regulae: Groups can have scripts. If you click on a button in a group, the "mouseUp" message goes first to the button, then the group. Thus if the button has the script:

Code: Select all

on mouseUp
   put "button"
   wait 2 seconds
   pass mouseUp
end mouseUp

... and the group has the script:

Code: Select all

on mouseUp
   put "group"
end mouseUp

... clicking the button will cause the word "button" to appear in the message box, followed two seconds later by the word "group". This may seem a very simplistic example, but it's clear, and also illustrates the need to "pass" the message if you handle it in a control's script. It never hurts to be reminded, because it's such an easy thing to forget to do.The message goes no further than the group, because we handled it in the group's script, but did not pass it on.]
-----------------
Layer (synonym: partNumber)
Specifies the back-to-front order of objects on a card or the order of cards in a stack. Use the layer property to change the tab order of controls, or to change the order of cards within a stack. If the object is a control, it must appear on the current card in order for its layer to be changed; you can't set the layer of a control on another card.

The layer of a control is its order (from back to front) on the card. If two controls overlap, the one that covers the other has a higher layer. Each control is on a different layer.

To bring a control forward, set its layer to a higher number. To send it back, set its layer to a lower number. You use the form
set the layer of object to top
to bring the control all the way to the front, and
set the layer of object to bottom
to send it all the way to the back.

If you set the layer of a control to a number greater than the number of controls on the card, its layer is set equal to the number of controls.

The layer of controls also determines the tab order. When you press the Tab key, the next control whose traversalOn property is true becomes the active (focused) control. For example, to set the tab order of fields in a data entry form, set the layer of each field so that they are in order.

The layer of a group determines the back-to-front position of all the controls in the group at once. The group behaves as a single control, as far as its layer is concerned. When you group or ungroup a group, its controls retain the same back-to-front placement relative to each other, but the group as a whole moves to the front. The layer of a group is one less than the layer of the lowest-layered object in the group.

It is not possible for other controls to be interspersed between the controls in a single group. If the relayerGroupedControls property is set to true, and you set the layer of a grouped control to a number greater than the topmost control in the group, or lower than the bottom-most control in the group, the control is moved out of the group. If the relayerGroupedControls is false, you cannot set the layer of a grouped control without being in group-editing mode.

The layer of a card specifies its position in the stack. Setting the layer of a card moves it to the specified position in the stack.

Changing the layer of an object also changes its number property.
-----------------
Number (synonym: num)
Use the number property to find out what layer a card is on, to find or change a card's position, or to refer to an object. For all objects except cards, the number property is read-only and cannot be set. The number of a control is its layer on the card. Lower numbers are further back; higher numbers are farther forward. If you create several controls and don't change their layer order, the first control you created has the number 1 and the rest of the controls are numbered in the order of creation. The number of a card specifies its position in the stack. When you open a stack without specifying a card, the card whose number is one appears first. Setting the number of a card moves it to the specified position in the stack. (Cards are the only objects whose number property can be set.) You can refer to any object by specifying its number. [Regulae: while the number of a control on a card is read-only, its layer (a LiveCode synonym is partNumber) can be set. Note that "number" in this case is a property of (for example) a control, i.e. its layer number. "number" is also a function, e.g. "the number of controls", as in:

Code: Select all

put the number of controls

which gives you "how many" controls there are on the current card. Consult the dictionary's entry on the number function to see the specifics of "number" as a function.]
-----------------

Even if you've encountered the full entries in the dictionary, a combined summary may help to weave everything together- it certainly became clearer to me.

Something that is handy to know is that a newly created control appears on top of existing controls on the card, i.e. it has the highest layer (or partNumber). You can refer to this control as "the last control". For example, if you create a button by dragging one from the tool bar onto the card, then type into the message box:

Code: Select all

put the short id of the last control

... and press enter, the id of the button you've just created appears in the message box. "the last control" really becomes useful when you're creating something by script, then need to refer to it. I don't know if it's done that way in SuperCard, but in a discussion of LiveCode layers it's worth mentioning, for the possible benefit of future readers. Some of the earlier simple script examples were included with the same potential readership in mind.

While all of the above may be a useful start, often projects require something not specifically envisioned in the dictionary. The Forum is a great resource in these cases- frequently, someone has already achieved what is needed, and it can turn out to be quite simple.

It's very useful to know about the Cooliris danger- I'm looking at getting hold of a Mac fairly soon, and I'll keep well away from that problematic extension. The project you describe sounds very interesting- I rather hope LiveCode does meet your needs so we can hear more about it.

Regards,
Michael

[Randall Lee Reetz]

Richard,

You wrote:

If you're coming from a HC/SC background, one area from which LC derives so much of its outstanding performance may initially seem a drawback, but in practice is hardly ever an issue: it doesn't allow custom handlers to override built-in commands and functions.

Can you give an example so that I know exactly what I can't do in LC and why?

Thanks, Randall

[mwieder]

Can you give an example so that I know exactly what I can't do in LC and why?

In the OOP world it's useful to be able to override methods in a subclass that take the place of methods in the parent class. We can do this in xtalk by taking advantage of the xtalk message-passing hierarchy wherein you can write a myFunc() function in a card script, but then put a myFunc() function in a button's script that will take its place: the function in the button script will be executed *instead* of the function in the card script. The function in the card script will be ignored unless the message is explicitly passed in the button script.

You can't do this with functions and commands defined in the engine itself. You can't, for example, write your own exists() function for special purposes. It would be handy to be able to do this, but you can always write your own myExists() or whatever to get around this. The restriction means that LC can run much faster because the engine doesn't have to parse the internal commands along the message path each time, but instead can compile bytecode that executes in the engine directly. I will grumble about the lack of true OOP method overriding, but I'm not willing to deal with the tradeoff in execution speed this would entail.