Restricting a numeric "range" into an input field

Apologies for the lack of graphic detail, but this is what I have to work with:

Near the bottom we have “Angle”. This is the input field I’d like to “restrict”.

Firstly, I will be changing this to an integer, the above graphic doesn’t show that correctly: Temperature/Elevation/Angle, but consider it done.

The Range:
Whilst the Angle could be in the range of 0 to 360°, I’d like to restrict between 90 and 45. This may well be a good case for “Auto”, so probably the “Key-Up” event?

Complicating that, there MUST be 2 characters input first, before an evaluation is made. I guess using the LEN function - within the key-up event?

Although, the “glaring” possibility is just to use the UPDATE button, which will/should evaluate ALL inputs anyway. But, I think that if the user enters two numeric characters, then a number over 90, should default to 90 and below 45 will default to 45. That is to say, when the user releases the key AND there are two digits, the evaluation is made.

@Steve Kelepouris — I think the best here would be to check the key pressed in the KeyDown event. There you can return true to reject the character, and warn the user

Keydown? Yes, perhaps. I’ve never used keydown.

I’m not sure about how to “warn” the user. Message box = NO. The input field should be “Dynamic”.

@Steve Kelepouris — There are many ways to warn the user. It is really a personal choice and a user experience. Just off the top of my head:
• You can call Beep and block any KeyDown which would create an invalid value
• and briefly display a small error message somewhere near the control
• or display a message box after 3 beeps in a row
• You can accept any value but use a read background to notify the user that the value is incorrect

and so many other possibilities

Thanks Steph.

I think I’m wanting it both ways, which I reckon can’t be done. The simplest method is to evalute the input (and with other fields) is when the user selects the UPDATE button, which may as well say “Evaluate ALL the input values”.

Cutting corners, as in, eliminating one step and trying to make something “simpler” is the hardest thing. I want “STRICT” with “perceived” flexibility, if that make sense.

@Steve Kelepouris — Yes it makes sense, but you cannot go away from the fact that at least one value is INVALID. So you will need to notify the user about that sooner or later.

So you can’t escape from the fact that you will need to warn the end-user when he/she type in a bad value

That’s true. But to complicate things further, looking at the panel in the first post, If the user enters a value in the “Gross Weight” input box that is more than the “propellant weight” (in another window) then selects the the UPDATE button, they will be alerted to a different problem as well.

If I also include a warning about the “Angle” then the user will see two message boxes in a row. Lucky if the user reads the first message warning. Two warnings in a row, and unlikely the user will read both.

Therefore, that’s why I thought it may be best to take a different approach and make the Angle input dynamic, and leave the rest as is. The UPDATE button (when available) will also enable a RUN SIMULATION button.

This Software Solution is a Step-By-Step process, where preceding steps MUST be fulfilled, otherwise the user cannot proceed. It’s very difficult to achieve this for many reasons apart from the code. I’m trying to make a complicated process “seem” as simple as it can be to the user.

Every step in a procedure should be needed. Otherwise that step, by it’s very nature of being there, is in itself a possible point of failure. If you can eliminate unnecessary steps, via code and algorithms, then we are a good way there to achieve what we want.

It’s not easy.

Actually, Steve, it is relatively easy if you de-couple the UI and the data used to perform the function. Create a class that contains all the properties representing each of the data inputs or calculated values required for the process. At each step of the process, you only copy input data if it meets the validation rules: that other data element must already be present, for example values must be between 10 and 99 etc.

The keydown or lostfocus events can be where you code such validations. Either a “go” button or individually, the lostfocus events can ve where you do additional rules validation before you copy the data over the class (or window properties), and then launch the process if all rules are met. In short, in the UI, you validate some input rules. In the copy process, you validate pre-requisites and more complex input rules. When all rules are OK, then you are clear for copy. When all the data is validated, you are cleared for launch, so to speak.

You need to think in terms of process rather than features when rules must be enforced.

Thanks Louis.

I’m a bit confused. You keep mentioning Copy.

ie. “copy input data if it meets the validation rules”… “validation before you copy the data over the class”… “In the copy process”… “then you are clear for copy”…

Copy, copy, copy… By “copy” do you mean “retain”? or update default values?.. I’m not saying it’s wrong, I just don’t understand what it is you are getting at.

I mean take the value from a text field where it was typed and move it to the property of the class where it will reside once validated, until the process is ready (all prerequisites are met, all individual data elements were validated, complex validations were performed…) to use the data.

I used copy rather than move because I suppose that the data remains visible in the text field, popupmenu, etc. where it was entered. Move would imply that the source is cleared.

The idea is to validate each data entry field either as data is entered, or after it was entered but before you use it. When an entry is validated, it is stored in a different place where other more complex validations (which could involve more than one data field, for example) may be performed before the data is actualy sent to the process (computing or other).

Think of it as a kind of kanban. UI elements contain raw data, individually validated or not. The class contains individually validated data, and perhaps data that underwent complex validations. The computing function is passed fully validated data. 3 stages, 3 logical buckets. Your process may require more than logical 3 buckets, you know best.

Louis, your method reveals flaws in the way I’ve gone about things. More than I wanted to know. (gulp)

Nevertheless, much to consider, and time to do some reading, especially regarding creating classes.


Don’t worry. It took me several iterations of one of my applications before I got it sort of right. Now, I spend some time up front reducing every process step of an application to an algorithm. That really helps with the data design. You know that the algorithm is deep enough when it explains the raw data, what steps need to be taken with it in order to validate it, and what is the next step that is going to consume it without further treatment.

If you are uneasy with classes, Window properties would serve the same purpose, they would only be less portable.

I might be missing something and confess I didn’t read all above. But perhaps a different approach would be to make the angle input a slider with the range of 45-90? You could leave the text field and update with slider input, but make it read only, and put the slider beneath it to “adjust” the value.

In that case he should rather use a label than a TextField …

Well thanks Joseph, that does make sense. Sometimes it’s hard to see the forest for the trees. I suppose one could say:

Nevertheless, that solution seems somewhat problematic. Not because of the idea, but because of the implementation using WIN7/Xojo2016R3.


The top half of the image shows how the slider looks in the IDE. The bottom half, how it looks in Debug mode. What The???

Apart from the transparency issue, the worst thing is that the range of the slider has “shrunk” dramatically in scale along the horizontal axis (confirmed via testing). Maybe I’ve done something wrong, but it looks like a bug to me.

Thanks Markus, I will do so if and when the above issue can be solved.

In the end, I may have to “roll my own” control, or go back to my initial idea.

What I do:

P.S. Do image tags no longer work for Dropbox files?

Dunno about dropbox, I use Imgur.

This is the image from the link above (hope that’s ok with you Markus):

On the surface, I really like this approach and have seen it before, but there is a flaw - in that it won’t work with how I want things to work. Let’s pretend that it’s “Voltage”, “Angle” or the weight of “Elephants Testicles”. For the purpose of the exercise, there is no difference.

To me it looks like the voltage input field is accessible (and all the others). Using the up/down arrows is all well and good as it can be restricted by code, but if the user is able to input a value into the field, then it should also be restricted.

Therefore I find myself still in the same situation as described in post #1. But… ummm… perhaps getting closer to a solution? :slight_smile:

[quote=422255:@Markus Winter]What I do:

P.S. Do image tags no longer work for Dropbox files?[/quote]
Yes, they do, you need to add ?raw=1 to the end:


Dear Alberto ???

Ah yes, now I see what you mean. Good value and info for posting images on this forum. Appreciated, but perhaps it doesn’t add or help to question that i’ve asked.