Restricting a numeric "range" into an input field

@SteveKelepouris Thankyou Dave, but I don't want to TAKE something. Sometimes I like to explore things myself. I don't expect to spoonfed.

Sometimes I'm happy to blunder around and learn some things for myself, and this is one of them. On other occasions, I'm happy to copy/paste the code and be done with it.

It's nothing personal, I'd just like to try to sort this out my way. It may well end up that I fail in my quest, and you (and everyone else in this thread) post "I/we already told you so, why didn't you read it?"... and people get pi**ed off and think I don't respect or value their opinion/s. That's far from the truth.

Well nevertheless, I do what I have to do.

He is not spoon feeding you, just showing you how one developer would go about coding this task. We have all learned from code examples in our never ending quest for knowledge. :D

No offense Steve... but if you prefer to blunder around (which I get). then why ASK about it?

I've been in this business for more years than I can count, and find I learn more by example than anything else. Do I blindly cut and paste code? No... I study the examples to understand the concepts, and then adapt as required.

I do as much data validation as possible in KeyDown and inform the user or simply discard keystrokes.

I validate the field in LostFocus. I inform the user of the problem, but let them continue to the next field.

In the form submission button, I evaluate each field that has been modified or is in an error state. If any field fails validation, I inform the user and set focus on the first field that failed. (Note that if the field is being evaluated due to being in an error state, the user has already been informed, so you don't have to inform them again.)

If all fields pass validation, then I validate the form as a whole - do all the values make sense in relation to each other?

Since field validation occurs in multiple places, each field has a validation event definition, so the code resides in one place and is part of the field itself.

This means, of course, that every field is a custom subclass as is every window. That allows you to have a lot of common code built into the subclass and eases the coding burden. For example, for a TextField, I can tick off the kind of data that is allowed in the field in the inspector.

numeric

alpha

punctuation

minus sign

hyphen

date

etc

I don't have to code the validation for those in each field, it's already handled by virtue of being a subclass.

Another advantage to this approach is I only have to extract data from the fields that have been modified. That helps reduce potential problems caused by data conversion. It also allows you to decouple the display format of the data from the data entry format. One example of that would be dates - they can be displayed as MM-DD-YY, but entered as MM-DD-YYYY. (I don't actually do that, but it's the first example that came to mind.)

Is there a way for me to make the forum automatically "like" every post @Tim H ever makes? I learn from every single one. Truly, sir, you are a noble spirit and have given generously of your great expertise as long as I've been a member here. Thank you.

@SteveKelepouris if the slider range is too cramped but you still want something very quick and dirty, you can just use a PopUpMenu and populate it with the values - integers 45 to 90 is not that long a list.

I'm having a bit of a break with coding at the moment and hopefully get back into it soon, otherwise I'll forget everything.

Although "my" program solution is further than I've ever gone (3yrs and ongoing) then I come to the conclusion and face reality that perhaps it will never be finished.????

Maintaining interest and momentum as the days/weeks/months/years go on is becoming a burden.

My first love is Music. I've had an ear infection for the last 5 weeks. Not a big thing, but not good and perhaps it has clouded my view on everything. Too much information, I'm sure. But nevertheless, I do need/would like to finish my 3yr project. Isn't he?

It's always the little things that I get caught up in. Often they are most important things. Give me some time to evaluate the solutions posted, in that "Restricting a numeric "range" into an input field" which I posted in the first place, was the question asked. I think the solution/s have been posted.

I'm sure that what is posted will work, but give me some time to resolve this in my own way. A task that becomes harder day by day by day, but I know that I'm the one who has to solve and agree with it (ie. agree in my dumb way) - no disrespect intended to anyone.

If I fail, I can assure you "I" will be the one to blame, If I get my sh*t together, then that would be good and preferable - to me.

Is the feature being discussed here important? Yes, I think it absolutely is. Not just because I like it that way, but there could be possible legal ramifications.

Without getting too much into the "nitty gritty" of it, there are rules and regulations regarding the angles at which a model rocket or pyrotechnic rocket should be launched. In fact, my 90 to 45 degrees is just an example for the purposes of the discussion.

In reality 90 degrees (ie. straight up) would be dangerous. So best to restrict that to 80 degrees, and then according to rules, you shouldn't launch at less that 60 degrees.

I'll put it this way: Imagine launching a pyrotechnic rocket, that is a rocket that has on the top of it a "shell". The shell is filled with "stars", meaning stars in this context are small pieces of pyrotechnic compositions that ignite and produce colour or glitter effects.

That's what we all love to see. If that rocket containing the shell (the vessel that holds the stars) is launched straight up (ie. 90 degrees) and the "time fuse" which ignites the burst charge in the shell fails, then re-ignites, falls to the ground and explodes......

Model Rockets have a different purpose, usually altitude is the main game and a recovery system is employed. A parachute or streamers to slow down the decent.

So I have to be careful in a way. Most "pyrotechnic professionals" would already know the dangers and would probably have no interest or need to use my software. My software (will) enable professionals (and amateurs) to measure the thrust performance of the motor, and also display "prediction" of the final altitude. My philosophy is that it's better to have more information than less.

In any case, there are MANY tutorials out there for making rockets and some failure where people get their fingers blown off, or get badly burnt.

I can't guard against stupidity, yet I also don't want to leave myself open for potential litigation. You may well ask "why the heck am I doing it all then?" Well, because pyrotechnics and model rocketry have been an big big interest of mine for many years, and I do enjoy software programming. My Software is just a "tool".

I probably should have said. "Skip this one unless you enjoy watching something where nothing really happens, unless you understand the point".

btw. It's not a "thrust gauge" it's a "Load Cell".

The point of that video was to show the load cell when "loaded" and the weight is moved off axis and reads the same value. Doesn't matter. It is an engineering point, and nothing to do with software. perhaps I should not have posted it I guess. but I just wanted to show the "evolution" and the reason why I do what I do.

@Beatrix W You are afraid of being finished. I get that, too. From your screenshots the app looks like version 2 or 3 and not version 1.

The most important thing you can do is to get your app to users. Is the feature you are discussing here important?

Fix some remaining - important - bugs and find some beta testers.

That's good advice Beatrix.

I do tend to get caught up in the details, like "what if the user did bla bla bla..." I have spent countless hours trying to come up with ways to ensure the user can't make an input error (not just with this one). The reality is that these "what if" scenarios are unlikely to occur anyway, and I'm wasting time and diminishing my brain cells (2048 at last count).

As pointed out previously, I have an UPDATE button which will evaluate the user input anyway/s. The update button will only EVER EVER be available providing the previous steps are valid. Therefore easy enough to capture input errors. The Angle input is just one of "inputs" that will be evaluated.

What I have done is very basic to simplify the range when the user selects the UPDATE button:

The User has no warning of this, and the values will change (if out of range) accordingly, but it's very simple. However, it will be explained in the Help system. The user is unlikely to cause this event anyway, if they do, then nothing bad will happen to them, and my sanity will remain intact. Perhaps forget the user experience in this case?... If they don't like it, then they can find something more interesting to do.

Perhaps Macrame or Reading Tarot Cards (not that there is anything wrong with that), I dunno, that's up to them!!... I guess I could probably facilitate this by linking them to the appropriate website... Just thinkin'...