So I settled for FIELD. It makes it much easier to simply 'do the source and use the field directly in your existing layouts.

Version 0.0.2 offers using the +/- buttons and the scroll-wheel to adjust the numbers in numeric fields as well as restricting the length of the field.

Source, docs and version history.

It's not hard to get your needs quickly beyond the capabilities of the ordinary VID field, so I made SUPERFIELD (good name there) to allow a bit more flexibility. Not much, but enough to give you more to use fields for without resorting to messing around with the FEEL object.

I'm basically rewriting some old code I used for custom fields, so there'll be more to come. I've uploaded the first little version to the downloads section.

I discovered that Rugby evaluates anything before it's returned, so if you are returning any-word! values (words, lit-words, etc.), like this:

test: does ['some-word]

Rugby will attempt to evaluate some-word.

If it fails, because it's unset, Rugby returns an error in an internal function. I believe this to be incorrect, because this breaks the paradigm of having Rugby be able to serve any REBOL function unchanged.

I've not had this behavior verified as correct by Maarten Koopmans, but I made a patch to the to-result that passes any-word! values through, while other return values are still evaluated. If you are using code, that relies on the word to be evaluated before being returned by Rugby, your code will break.

UPDATE:

An improved fix checks for set values in a returned word, so if your word has a value, it will be evaluated. Words that don't have a value, as well as lit-words will still not be evaluated. It has been approved by Maarten as a fix.

I've uploaded a patched version here.

ATTEMPT is a really nice function. It makes it simple for you to skip errors in code if a part of your code fails. Such as:

>> a: 2

>> b: 0

>> attempt [a / b]

>> none ; We're fine. Keep moving.

This is good if you don't really care about a math error, it's pretty obvious what goes wrong and just want to keep going.

I use this combination often:

any [attempt [a / b] "Math Error"]

As it's simple enough to debug by PROBE'ing a or b.

Therefore if you are building a larger script for a customer, and don't want the console output pop up suddenly in his/her face with strange error outputs, it can be quite tempting to just say:

attempt [

  huge amount of code, perhaps an entire application

]

ATTEMPT will not only keep your code running now, it will also completely hide otherwise obvious errors. If you use it like this, you lose of control over your code. Your application will not only not crash, by not responding to a user action, but you won't know at all what goes wrong.

Never use two nested ATTEMPTS to print the number of candybars per child:

unit: " candybars per child"

print any [

  attempt [

    join any [

      attempt [candybars / children] default-value

    ]

    unit

  ]

  "Uhmm.. error!"

]

Any number of things could be wrong in even this small bit of code:

• 
  
• default-value might not be set or is the wrong type
• 
  
• candybars and/or children might not be set or are the wrong type
• 
  
• children might be 0.
• 
  
• Heck JOIN may even have been redefined by accident in a different section of your program! You won't notice...
• 
  

It really is much better to do proper handling of errors than just to ignore them in the long run, It leads to unpredictable behavior and frustrating all-night debugging sessions.

So you want to play with the effects attribute of a face, but find it difficult to get the right look? You may want to speed up the feedback between writing the code and looking at the actual results. There's nothing like near real time feedback from the code you are currently writing, as it can shave many seconds and trivial debugging off your code refinement cycle. Seconds become quickly become hours, if you refine your code a hundred times, before you are happy.

Therefore I usually build a small helper tool to make things more interactive when doing REBOL graphics. These tools are purposely kept really simple, usually around 10 lines of code. You don't need more than that.

For processing the effect attribute, you could build a small tool that presents a face of a comfortable size to view your effect in and a text area for you to write code in:

The code is almost as simple:

view layout [

  space 2 across origin 4

  ef-box: box 300x300 with [color: none] edge [size: 1x1]

  ef-text: area 500x300 font [name: "courier"] [

    if attempt [load face/text] [

      ef-box/effect: load face/text

      show ef-box

    ]

  ]

]

You can now type in your effects code and the face in the left side will update, when you unfocus the text area.

When you are happy with the effect code, you can copy the code and paste it inside your source code. Quick and simple.