Where to put Custom Handlers and Custom Properties

[Bantymom]

Thanks to everyone here, I am getting a very teeny tiny bit more sophisticated in the way I put my scripts together. Since this has been an evolving process, however, there is quite a bit of scripting in my game that is bulky and awkward. I am at a stage where I want to go back in to streamline and reorganize things.

One of the biggest things I want to do is to write custom handlers for the big chunks of things to be referenced where needed later. One, it will make it possible for me to use those bits of code in other places (resetting things especially), and two, it will make it easier for me to remember what each part does, lol!

The other big thing is to go through to replace my global variables with custom properties.

In both cases, I need to decide where to store those things.

I have had two main thoughts on this and would very much appreciate some help.

1) The Handlers: Put all of the custom handlers in the Stack Script so they will all be in one place and easy for me to find if I need to make changes, or put them in the Card Scripts of the objects which calls upon them (but then, there might be objects on different cards calling on the same script). Does it take RunRev longer to go find and use custom handlers when they are buried all the way down in the Stack Script?

2) The Custom Properties: Assign all of the custom properties to the Stack Property Inspector (I hope you know what that means. I don't know a better way to explain that), or assign them to the Cards they might most likely be used on. By assigning them to the Stack, I always have to add "of this Stack" when calling upon them, instead of just saying "put the cLevel into tField," though I think if I have them on that Card, I might still have to do that and I might have more difficulty in remembering where I put them!

I am trying to compile in my mind a collection of "best practices" for RunRev scripting so that true learning will take place and I will be better at this in the future. A true discussion on the pros and cons of the various possibilities will be more helpful to me than just being told what to do. Knowing why one person does it one way and another does it another way really helps me to understand and tease out the subtle differences. I would greatly appreciate it if you would respond with the practice you use and why.

*sets up a comfortable discussion area with comfy chairs; a smart board; boxes of pencils, pens, and stickies; and plates of brownies, rice-krispie bars, and chocolate-chip cookies*

Cheers,
Bantymom

[Mark]

Hi Bantymom,

I use global variables really only for values that are needed throughout the entire application, during one session, regardless of which documents are open.

Custom properties are a great way to store data that are needed in every session. If these data are variable and have to be stored between sessions, or if the data in these properties is specific to individual documents, then you can store them in a separate stack and store this stack as a document or as a preference file.

You can call properties by means of a function (or command), which returns (or sets) the property. This way, you don't need to write "of stack bla" or "of card bla" all the time.

To determine where to store custom handlers, you might want to read a little in the documentation about frontscripts, backscripts and the start using command.

Kind regards,

Mark

[bn]

Bantymom,

I guess it is all a little about personal style and size of the project.
If I want to avoid globals, which I do, and I want to replace them I often "attach" custom properties to the stack. Other times if I change a specific object I might attach custom properties to that object. The card is a good place for them if custom properties pertain to changes that are confined to that card. Since custom properties are so versatile it also depends on what is in the custom property. You can as you found out store images in custom properties. Then again what part of your project needs them. It all depends.

moving code down to the card or stack level is something I also do for easy maintenance. So you are fine there. Always remember if you have a mouseUp handler or any other for that matter you want to place in the stack script and you have one card that has a number of controls that need a different behavior you can place a mouseUp of whatever handler in the card script of that card and all these messages will stop at the card level, if you dont pass them. So you could "customize" your handlers.

What Mark says about front/back scripts and start using script can be very powerful but is rarely needed in small projects. I would not worry about it. It adds a layer of complexity that you will get to when you need it.

So now I will get out of my comfy chair and go to bed.

regards
Bernd

[Bantymom]

Store images in custom properties? I know I can attach a custom property to an image, which has been working very nicely, and I even figured out how to attach the script to an image automatically when I paste it into place (though now I won't need to do that as I can attach the script to the Image Place Holder Object Thing), but no, I didn't know I could store images in custom properties. If I can do that, it will solve many problems I am about to get myself into (oh, so many rewards I'm finding). If I can do that, I can store each student's "ribbons" in their own custom property instead of having to make a separate card for each one.

[Klaus]

Hi Bantymom,

Store images in custom properties?

Yep, pretty easy!

Just store the (binary) image file in the custom property:
...
set the cImage1 of "image1" to url("binfile:" & path_to_the_image)
...

To "reset" an image:
...
put the cImage1 of "image1" into "image1"
...

Cool, isn't?


Best

Klaus

[bn]

Bantymom,

I thought about your undo problem a bit. I did notice that when you hit the black dividing lines of the drawing with the bucket tool the color could "bleed" and fill a lot more area than intended.

Well I did a modification of your painting card stack you posted. It uses 2 custom properties of the image to store an initial image and an image of the last version before applying a color. So you can either undo the last painting action or reset the whole image. It turns out that Rev/Livecode sends a undoChanged message for paint action. I use this in the card script. The undoChanged message does not do anything by itself but you can use it to take action.
Two new buttons "reset" and "undo" on the card. And changed to the "paint" button. Have a look. Had to remove the teacher image to upload

regards
Bernd

[Bantymom]

Hi Bantymom,

Store images in custom properties?

Yep, pretty easy!

Just store the (binary) image file in the custom property:
...
set the cImage1 of "image1" to url("binfile:" & path_to_the_image)
...
To "reset" an image:
...
put the cImage1 of "image1" into "image1"
...
Cool, isn't?

So, for example, when I upload those 3 images that we've been working on, instead of putting the image into the Empty Image Control Place Holder Box, I can put them directly into custom properties cChalkDrawing, cLineDrawing, and cColoredDrawing? Yes! So very Cool!

Bernd,
I have some questions about your response regarding my Undo problem. I hope you don't mine, but I posted them back at the original thread so I will be able to look back for the answers more easily:
http://forums.runrev.com/phpBB2/viewtop ... 272#p27272
There are brownies waiting there.