[Solved] TComboBox Query

[J-G]

This would be safer:

Thanks Howard,  You'll appreciate that my brain is still stuck in the time when 'Try' didn't exist in Pascal

I know it's the way to go and I have used 'Try' in the recent past but seldom remember that it is available.

Regrettably, a simple change to using     
  If TryStrToInt(BA_Num_List.Caption, Thread.Num) and (Thread.Num in [0..16]) then
will not compile since that expects Thread.Num to be a LongInt whereas I have in declared as 'byte'  -- it will only ever be 0 to 16 --  even changing the declaration to LongInt caused further compilaion problems - this doesn't appear to be a problem when declared as 'byte' or 'word' but as 'longint' it does;  and I don't have the wit to understand why 

Colour me stupid!!   

It's much better to modify the declaration of the variable in question rather than a similarly named variable in another record!!!  D'oh!

Your second responce came in during my edit Howard and I can see how to get around the inappropriate declaration thanks. The first suggestion now works perfectly of course (you knew it would!) and is 'cleaner' than having to use another local variable so I'll stick with 'LongInt'. Adding 3 bytes of data isn't going to break any memory bank 

[howardpc]

Code: Pascal  [Select][+][-]

1. procedure TForm1.BA_Num_ListEditingDone(Sender: TObject);
2. var
3.   tmp: Longint;
4. begin
5.   BA_Err.Hide;
6.   If TryStrToInt(Selection.Caption, tmp) and (Byte(tmp) in [0..16]) then
7.     begin
8.       Thread.Num := tmp;
9.       Get_BA_Info(Thread.Num);
10.       Calc_and_Show;
11.     end
12.   else
13.     BA_Err.Show;
14. end;

         

[Zvoni]

Your second responce came in during my edit Howard and I can see how to get around the inappropriate declaration thanks. The first suggestion now works perfectly of course (you knew it would!) and is 'cleaner' than having to use another local variable so I'll stick with 'LongInt'. Adding 3 bytes of data isn't going to break any memory bank 

https://www.freepascal.org/docs-html/prog/progsu60.html
Your record probably took the same amount of memory with the old Datatypes....

[J-G]

https://www.freepascal.org/docs-html/prog/progsu60.html
Your record probably took the same amount of memory with the old Datatypes....

I do normally consider record size when I start a data-base project  -  even adding in a 'buffer' which allows for expansion as and when originally unforseen data is needed  - but in ths case the project was organic - It grew out of a simple 'want' rather than a 'need' but is now quite a useful engineering tool .... if you are into threads 

I spent most of yesterday adding in 'Error Checking' to circumvent a program crash when a user hit '/' or ',' rather than '.' or even entered letters where numbers are required - just in case! If it can't possibly happen it almost certainly will!

I've also looked at the record declarations and changed 'double' to 'single' now that I know what 'range' of numbers is really needed. There are only 5 Records, 92, 83, 78, 23 & 11 bytes.  The 83 byte record has 10 uses but all the others are single use. The shame is that that record is the one that increased by three bytes which takes it out of the 16 byte multiple.

[Zvoni]

'.... if you are into threads 

Funny enough: i do work for a trading company for fasteners….. imagine that….

As for your „characters where only numbers allowed“
Look at my codesample. There is code for the KeyPress-Event allowing only digits, backspace, delete and Enter. Adding a dot is simple

[J-G]

'.... if you are into threads 

Funny enough: i do work for a trading company for fasteners….. imagine that….

At one time 'threading' was my Bread & Butter, I was the commercial Export manager at Herbert Small Tools having previously served my time as a tool-maker at Matrix - two companies very well known in Coventry  -  and later at a smaller company whose raison d'être was 'Fasteners'   -  it's a small world 

As for your „characters where only numbers allowed“
Look at my codesample. There is code for the KeyPress-Event allowing only digits, backspace, delete and Enter. Adding a dot is simple

I have looked at your code and yes, had noticed a 'Key-Press' event - when I realized that my need for a drop-down list was secondary and I just needed a 'number' I solved all the issues using existing basic code.

Because I want to provide 'real world' simplicity which essentially means that I don't want to restrict the user by demanding that they always enter decimal parameters I've developed a 'Fraction' entry method which has to have space & division as well as numbers & decimal point. In addition - having an eye for good design - I also decided to use a 'centre dot' to display decimal numbers so that added yet another character to the list.

Therefore the Diameter (or any imperial parameter) can be specified as (say)  1.5625,  1·5625  or 1 9/16  --  3/4, 0.75 or ·75  etc.  with all errors trapped. It would be a simple matter for an end user to accidentally hit either '.' or even ',' instead of '/' so these events also have to be trapped.

I had looked at components which offered a 'Numbers Only' but they do just that  --  not even a decimal point or negative sign  --  which I find less than useful.

Under DOS I developed a data entry system which looked at every key-press but I've yet to do the same under Windows - it seems somewhat more difficult 

[Zvoni]

Because I want to provide 'real world' simplicity which essentially means that I don't want to restrict the user by demanding that they always enter decimal parameters I've developed a 'Fraction' entry method which has to have space & division as well as numbers & decimal point. In addition - having an eye for good design - I also decided to use a 'centre dot' to display decimal numbers so that added yet another character to the list.

In that case i'd rather turn it around: Allow the End-User NOT to enter decimal notation, because face it:
Ask any mechanic on the street, which Screws he needs, and in 999 cases of a 1000 the answer will be along the line "Well, i need 3/16 and 3/8 mostly"
rarely will someone say a decimal, because, frankly, they don't even know the fractional value of it.
Parsing something like "1 9/16" should be easy enough since you have only digits, SPACE and "/".

You could even provide 3 TEdits: Full Inch, the Dividend and the Divisor and restrict it to real NumbersOnly.
[ 1 ] [ 9 ] / [ 16 ] --> "1  9/16"
[ 0 ] [ 3 ] / [ 8 ] --> "3/8" (First TEdit being 0 or blank)

[J-G]

In that case i'd rather turn it around: Allow the End-User NOT to enter decimal notation, because face it:
Ask any mechanic on the street, which Screws he needs, and in 999 cases of a 1000 the answer will be along the line "Well, i need 3/16 and 3/8 mostly"
rarely will someone say a decimal, because, frankly, they don't even know the fractional value of it.
Parsing something like "1 9/16" should be easy enough since you have only digits, SPACE and "/".

You could even provide 3 TEdits: Full Inch, the Dividend and the Divisor and restrict it to real NumbersOnly.
[ 1 ] [ 9 ] / [ 16 ] --> "1  9/16"
[ 0 ] [ 3 ] / [ 8 ] --> "3/8" (First TEdit being 0 or blank)

Whilst I understand your argument Zvoni, I don't think that option would be efficient in the overall scheme.

The Program has to handle both Imperial & Metric threads and Metric Threads don't use Fractions!

There is only one TEdit for [Diameter] and that must handle both measures.

If you would like to see the program, I could make it available via my web-site or even as an e-mail attachment - by all means send me a message with your e-mail address.

[Zvoni]

The Program has to handle both Imperial & Metric threads and Metric Threads don't use Fractions!

Uh, wrong!
https://en.wikipedia.org/wiki/ISO_metric_screw_thread
below M4 there are fractional threads.
I know that for a fact, since we do have clients using those diameters.
But i agree: Once you pass the M4 "Barrier" there are no more fractional diameters.
Then the confusing thing starts with "Fine-pitch" --> "ISO4014-M48x3x600" instead of "ISO4014-M48x600" (regular pitch, which is 5)

[J-G]

The Program has to handle both Imperial & Metric threads and Metric Threads don't use Fractions!

Uh, wrong!
https://en.wikipedia.org/wiki/ISO_metric_screw_thread
below M4 there are fractional threads.
I know that for a fact, since we do have clients using those diameters.
But i agree: Once you pass the M4 "Barrier" there are no more fractional diameters.
Then the confusing thing starts with "Fine-pitch" --> "ISO4014-M48x3x600" instead of "ISO4014-M48x600" (regular pitch, which is 5)

Sorry Zvoni - you've mis-understood what I mean by 'Fractions'  -  I'm very well aware that the ISO Metric thread standard includes 1.2, 1.3, 1.5  etc. but they are never referred to as 1 1/5, 1 3/10, 1 1/2 - just by their decimal figures. ASME B1.13M - 1983 doesn't list below 1.6mm and BS3643 : 1981 does list 4.5mm Ø in Coarse & Fine and 5.5mm Ø in Fine.

There is no reason at all that some designer could not specify metric threads above 4mm which are non integer diameter either  -  my program is specifically designed to handle such eventualities.  Just because there is a 'Standard' doesn't mean that it has to be adheared to
The Unified 'Standard' is one of the most difficult to handle. Not only is there UNC & UNF there's also UNEF, UNS and all their 'constant pitch' series.

My program also handles Buttress threads which come in both Metric & Imperial and with various 'angles' - that was a 'challenge' !! - Löenhertz is another form which is Metric. BA is an oddity being Metric but using a Number Series. Below ¼" the Unified series also uses a Number series - as yet I haven't made specific reference to that, the results can be computed of course - just by specifying the Dia. & TPI.
 

[Zvoni]

Sorry Zvoni - you've mis-understood what I mean by 'Fractions'  -  I'm very well aware that the ISO Metric thread standard includes 1.2, 1.3, 1.5  etc. but they are never referred to as 1 1/5, 1 3/10, 1 1/2 - just by their decimal figures. ASME B1.13M - 1983 doesn't list below 1.6mm and BS3643 : 1981 does list 4.5mm Ø in Coarse & Fine and 5.5mm Ø in Fine.

There is no reason at all that some designer could not specify metric threads above 4mm which are non integer diameter either  -  my program is specifically designed to handle such eventualities.  Just because there is a 'Standard' doesn't mean that it has to be adheared to
The Unified 'Standard' is one of the most difficult to handle. Not only is there UNC & UNF there's also UNEF, UNS and all their 'constant pitch' series.

My program also handles Buttress threads which come in both Metric & Imperial and with various 'angles' - that was a 'challenge' !! - Löenhertz is another form which is Metric. BA is an oddity being Metric but using a Number Series. Below ¼" the Unified series also uses a Number series - as yet I haven't made specific reference to that, the results can be computed of course - just by specifying the Dia. & TPI.

Ahhh, OK. Got it.

And yes regarding UNC, UNF.... you gotta love those Americans and their love for 3-letter-abbreviations...
I don't know how many times i've cursed the ASME-Standard, and that book weighs at some 4-5 pounds

[J-G]

Ahhh, OK. Got it.

And yes regarding UNC, UNF.... you gotta love those Americans and their love for 3-letter-abbreviations...
I don't know how many times I've cursed the ASME-Standard, and that book weighs at some 4-5 pounds

You can blame the Left-Pondians for many things (they even used a different 'inch' until 1959!) but I don't think the 3LAs are down to them    I'm sure BSW, BSF & BSC Pre-dated UNC etc. 

It seems somewhat ironic that you refer to the weight of the Standard in 'pounds' rather than kilos. I would have thought that your normal reference to measure would be Metric.

[Zvoni]

Ahhh, OK. Got it.

And yes regarding UNC, UNF.... you gotta love those Americans and their love for 3-letter-abbreviations...
I don't know how many times I've cursed the ASME-Standard, and that book weighs at some 4-5 pounds

You can blame the Left-Pondians for many things (they even used a different 'inch' until 1959!) but I don't think the 3LAs are down to them    I'm sure BSW, BSF & BSC Pre-dated UNC etc. 

It seems somewhat ironic that you refer to the weight of the Standard in 'pounds' rather than kilos. I would have thought that your normal reference to measure would be Metric.

LOL 
I was trying to accomodate you, since i'm not that unfamiliar with pounds since it directly relates to my sport (Skydiving)

[J-G]

I was trying to accomodate you, since i'm not that unfamiliar with pounds since it directly relates to my sport (Skydiving)

Ah,  -  I've been ambidextrously fluent in Metric and Imperial since serving my apprenticeship in the 50s/60s - I even quote my weight in kilos, though I'm still 5'8" tall 

I gave up 'sport' when I stopped ballroom dancing 40+ years ago

[Zvoni]

I gave up 'sport' when I stopped ballroom dancing 40+ years ago

Now, that‘s some dangerous sport……