BTW: what do I have to do to enter code in a proper formatting? If this has been discussed I have missed it
I swith onChange for onChanging and then it alerts you if the input is not a number and the field stay active.
Isn't that what you want ?
the number is just an example.
I actually need a multi-purpose field that in some cases is validated against a grep. In those cases the check makes sense only when the entry is finished, i.e. onChange and not onChanging.
As I said, I've got everything working but that one problem of the cursor being in the wrong field after onChange.
If there is any way to keep the field active from inside the onChange handler, the solution would be easy.
Otherwise I suppose I have to rewrite everything to check on onClick on the OK-button.
Validation in Script UI is not as simple as it seems on the surface.
It's one thing to have a single text field, have the user type something, validate it ,etc.
It's quite another to have an arbitrary number of fields with differing requirements, all of which need to be validated when the user enters data, an OK button needs to be enabled or disabled, and you have to catch the situation of data having not been entered in a required field.
Then it's further complicated by the behavior of the text field when a tab key is pressed as opposed to the enter key.
Editors note, I have not talked with the authors of ScriptUI on this. I played with it until I figgered out a way to make it work. My description is my guess as to what's happening based on what it took to make it work, possibly not exactly what ScriptUI is doing!!
A while back, Adobe commissioned me (when I was contracting) with developing a set of ScriptUI techniques that would mimmick the standard InDesign data entry widget, such as the MeasurementEditBox. Trying to make that happen with onChange and onChanging simply proved to be impossible as you can't get the arrow key events to nudge the values up and down.
In CS4, we got direct event support for ScriptUI widgets.
What I found was that when you press the enter key, you get an onChange event. You can cancel that event, and the focus will stay in the field. When you hit a tab key, you also get an onChange event; however, that event is evidently called during the processing of the tab key handling, and if you cancel the onChange (as a result of a tab), the actual focus shift to the next field happens AFTER the onChange event and does not fire an event on its own. That means the key press event of the tab key itself has to be cancelled in order to prevent the focus from shifting to the next field.
I am going to attempt to attach a script to this post that provides an example. In the past, that hasn't worked for me. If there's not script, just email me at firstname.lastname@example.org, and I'll send along the sample script.
This is an example of the MeasurementEditBox, as done in ScriptUI. I modified the original to intercept the Tab key, cancelling the tab when the field fails validation. In my original, I didn't not stop the focus change, I changed the bad field's background color to red. In this version, if the validation fails, I cancel the event (stopping the focus change) - see lines 265-268. I also modified the code that sets the background color. If there is a valid "last value", I set the control's text back to the last value - if not, I set the background color to red - see lines 271 - 284. The final change was to modify the "nudge" method to look for the tab key (it was just looking for the up and down arrow keys). If the tab comes through, I redirect the event to the validation routine, which cancels the tab key event if the validation fails - see lines 109-112.
The approach used here takes into account having multiple fields of differing types all be validated against data formats, min and max values, etc, and handle the enabling of an OK button.
I have a set of these, mimmicking - MeasurementEditBox, AngleEditBox, PercentEditBox, and IntegerEditBox. Thinking about it, I've zipped up the set and will attempt to attach here. If it fails, email me. The script that I described here is MeasurementEditBoxDefValue.jsx.
ScriptUI Validation.zip 41.8 K
Whoa, it worked! First time for me!!
Bob this stuff is so cool!!
Does Adobe plan on doing anything with this, or it was to sit on your computer until we got lucky today?
I would love to see and access more of your ScriptUI magic
Bob, thank you so much. I'll dig my way though your code in the next days. This really looks good
That's about all I have that still works...
One of my favorites was done back in the CS2 days. I modified panel containers. I placed a checkbox or a drop down over the location where the text goes on a panel.
For the checkbox, clicking the checkbox activated/deactivated the panel. For the drop down, the panel was set to be a stack, and the drop down controlled what was visible.
Sadly, I couldn't get these to work beyond CS2. The drawing routines were causing the overlaid controls not to draw correctly. It likely still can be done; but, I haven't taken the time to figure it out. It would be a nice feature to add to your kit, Steven.
Hi Bob you mean something like this. It can be done manually with Rapid ScriptUI (took about 10 minutes to work it out, and code to enable disable buttons or change stack must be written manually, though it isn't very hard.) but there isn't an easy class type of way of doing it. I attached the code for this image in text file.
Bob how about this piece of code http://forums.adobe.com/message/1114077#1114077Anyway I would love to add these type of features to Rapid ScriptUI by creating a library with your routines, however I don't have the time for it now, and I'll talk to you before I do anything like that.
One more question. Where is Dave Saunders, he hasn't been on here for a while, I hope he's allright?
code.txt 7.6 K
Thanks for your concern. I've been so busy the last few weeks the forums had dropped off my priority list. In addition to my regular full-time job, I'm also doing most of what was supposed to be my wife's full-time job -- she's been sick with a virus (not the flu) for the past three or four weeks, so I've just been overwhelmed.
She's getting better, but the workload is going to be intense through November.