Author Topic: Very Odd Behaviour of Control Object Value  (Read 9559 times)

0 Members and 1 Guest are viewing this topic.

Offline Qwerkey

  • Forum Resident
  • Posts: 755
    • View Profile
Very Odd Behaviour of Control Object Value
« on: March 31, 2020, 11:23:21 am »
Still working on the Gravitational Simulator, I found an instance of Control Object Value oddity.  The following is part of the SUB __UI_KeyPress (id AS LONG) (Code here will not function as only relevant lines included):
Code: QB64: [Select]
  1. SUB __UI_KeyPress (id AS LONG)
  2.     'When this event is fired, __UI_KeyHit will contain the code of the key hit.
  3.     'You can change it and even cancel it by making it = 0
  4.  
  5.     IF __UI_KeyHit = 27 AND NOT Paused%% THEN 'Esc key
  6.         IF DoCalc%% THEN
  7.             CALL ThisIsAnExParrot
  8.         ELSE
  9.             SYSTEM
  10.         END IF
  11.  
  12.     ELSEIF __UI_KeyHit = 13 THEN
  13.  
  14.         PRINT #2, id, HowManyBodiesTB
  15.         CtrlIndex% = WhichIsIt%(id)
  16.         PRINT #2, id
  17.  
  18.         SELECT CASE CtrlIndex% 'id
  19.             CASE 89 'HowManyBodiesTB
  20.  
  21.                 IF VAL(Text(HowManyBodiesTB)) >= 2 AND VAL(Text(HowManyBodiesTB)) <= 11 THEN
  22.                     Control(BodyDataFR).Hidden = False
  23.                     SetFocus BodyMass1TB
  24.                     Index% = VAL(Text(HowManyBodiesTB))
  25.  
  26.                     PRINT #2, Index%, Text(HowManyBodiesTB), id, Text(id), CtrlIndex%, HowManyBodiesTB
  27.  
  28.                     FOR M% = 3 TO 11
  29.                         IF Index% < M% THEN
  30.                             FOR K% = 8 * M% - 7 TO 8 * M%
The control HowManyBodiesTB has just had a carriage return, and the program enters the SUB.  The value of HowManyBodiesTB is 54, and I convert this into the number CtrlIndex% whose value is 89.  The SELECT CASE CtrlIndex% enters position CASE 89 and the program errors at the FOR/Next loop at the end.  I have added some extra lines to output values to a text file.  The output values are:

54, 54
54
5, 5, 64, (blank), 89, 54

In order these are the values of:
id, HowManyBodiesTB
id
Index%, Text(HowManyBodiesTB), id, Text(id), CtrlIndex%, HowManyBodiesTB

From the first two lines we see that id = HowManyBodiesTB = 54 as expected
From the third line we see:
The value of Index% = 5; Text(HowManyBodiesTB) = "5" as expected
id = 64 Changed from 54 for no reason
Text(id) is blank because id is no longer 54 !!!

I have no idea why this is happening.  Nothing occurs between where id = 54 and where id = 64.
Any ideas?

Offline Pete

  • Forum Resident
  • Posts: 2361
  • Cuz I sez so, varmint!
    • View Profile
Re: Very Odd Behaviour of Control Object Value
« Reply #1 on: March 31, 2020, 12:23:50 pm »
I would think the id variable, assigned as long, might be DIM'ed somewhere else as SHARED, and then I would check the SetFocus BodyMass1TB SUB and see if it is being changed there. Honestly, unless I'm missing something, there just isn't anything else I can see in the code as posted that would change the id variable.

Pete
Want to learn how to write code on cave walls? https://www.tapatalk.com/groups/qbasic/qbasic-f1/

Offline Qwerkey

  • Forum Resident
  • Posts: 755
    • View Profile
Re: Very Odd Behaviour of Control Object Value
« Reply #2 on: March 31, 2020, 12:30:42 pm »
Pete, thanks.  I think that I must be suffering from Virus-induced anxiety!  Like you, I just cannot figure this out.

Offline Qwerkey

  • Forum Resident
  • Posts: 755
    • View Profile
Re: Very Odd Behaviour of Control Object Value
« Reply #3 on: March 31, 2020, 12:42:51 pm »
@Pete, even more thanks.  I tried printing id before and after SetFocus BodyMass1TB and the value of id changes.  I am not going loony, after all.  The medics can start reducing the dosage.

@FellippeHeitor Is this supposed to happen?  I have always assumed that id is the value of the Control entering the SUB and does not change.  But it changes within that SUB to anything that has some InForm routine.


Offline TempodiBasic

  • Forum Resident
  • Posts: 1792
    • View Profile
Re: Very Odd Behaviour of Control Object Value
« Reply #4 on: April 04, 2020, 03:38:14 pm »
Hi Qwerkey

Quote
I have always assumed that id is the value of the Control entering the SUB and does not change.

But is WhichIsIt%(id)  an internal InForm routine?  In this case also I should be attonished.
However both it is original of InForm System both it is an your SUB  you solve using an intermediate variable .

Hey friend
Quote
I think that I must be suffering from Virus-induced anxiety!

do you think to installa a good antivirus? :-)
Programming isn't difficult, only it's  consuming time and coffee

FellippeHeitor

  • Guest
Re: Very Odd Behaviour of Control Object Value
« Reply #5 on: April 04, 2020, 06:33:31 pm »
I'm sorry I hadn't noticed this thread before.

A control's ID isn't likely to change but you shouldn't trust that its id will always be the same with each run.

A few questions: is WhichIsIt% an array or a function?

Also, why not just use the id directly?

Code: QB64: [Select]
  1.        SELECT CASE id
  2.             CASE HowManyBodiesTB

FellippeHeitor

  • Guest
Re: Very Odd Behaviour of Control Object Value
« Reply #6 on: April 04, 2020, 06:35:56 pm »
Please notice I'm not judging your approach, but rather trying to understand your logic, so I can help further.

Offline Qwerkey

  • Forum Resident
  • Posts: 755
    • View Profile
Re: Very Odd Behaviour of Control Object Value
« Reply #7 on: April 05, 2020, 04:53:36 am »
Please notice I'm not judging your approach, but rather trying to understand your logic, so I can help further.
@FellippeHeitor Not judging my approach: that's a good thing because it was your approach!  When I was actually doing this project (as opposed to now when I'm tarting up a few loose ends), you were spoon-feeding me.  In this __UI_KeyPress subroutine, but further down and not shown here, there is an array of text boxes (7 x 11) each needing input and data manipulation at some stage, and to use the actual id Names would have been extremely unwieldy, and so you got me to convert the Control Names into a number array.  That just made the coding a good deal easier to do and understand.  WhichIsIt% is a function to convert id into the array index.  Honestly, it does make the coding simpler (and more fun) than than if the Control name is used.
The oddity, as I saw it, was that id is the name (or rather number) of the Control which has just received a CR.  I would have expected id to remain constant at each SUB call - obviously it changes with each control that calls it, but for it to change within the sub (by a SetFocus to another control) was surprising.  To the foolish user (guess who!) SetFocus appears to have nothing to do with id.
I am thankful to Pete for pointing out where my error was occurring.

FellippeHeitor

  • Guest
Re: Very Odd Behaviour of Control Object Value
« Reply #8 on: April 05, 2020, 07:41:06 am »
Lol, I'm even happier I didn't judge it now!

Quote
I am thankful to Pete for pointing out where my error was occurring.

Well, is it solved then?

Also: I'm curious to see WhichIsIt again. Now that you mention it, it sounds like something that probably came up as STx was writing his InForm+Sxript spreadsheet.

Offline Qwerkey

  • Forum Resident
  • Posts: 755
    • View Profile
Re: Very Odd Behaviour of Control Object Value
« Reply #9 on: April 05, 2020, 08:02:53 am »
@FellippeHeitor Yes it is solved.  My cryptic message to Pete clouded his having solved the problem.  I was using id after SetFocus.  I just had to move the SetFocus to right at the end.

@FellippeHeitor @TempodiBasic WhichIsIt% was a Function of mine which I used to convert the id numbers into CtrlIndex% which is then used (the program knows what the value of CtrlIndex% is).  Actually, because of tidying up I removed WhichIsIt% (which was only required once after tidying) and put the translation code at the beginning of the SUB in question.

@TempodiBasic I'm glad to say that the anti-virus has worked perfectly - I'm just as stupid as I was before all this!

Offline Pete

  • Forum Resident
  • Posts: 2361
  • Cuz I sez so, varmint!
    • View Profile
Re: Very Odd Behaviour of Control Object Value
« Reply #10 on: April 05, 2020, 10:10:01 am »
I'm glad to say that the anti-virus has worked perfectly - I'm just as stupid as I was before all this!

Hey don't beat yourself up over it... That's my job, dammit!

Pete :D
Want to learn how to write code on cave walls? https://www.tapatalk.com/groups/qbasic/qbasic-f1/

Offline Qwerkey

  • Forum Resident
  • Posts: 755
    • View Profile
Re: Very Odd Behaviour of Control Object Value
« Reply #11 on: April 06, 2020, 06:23:52 am »
Just to confirm that use of the Control Array & CtrlIndex% is neater than use of the id Names, here is a comparison of the two methods for one later CASE in the SUB above:
Previous
Code: QB64: [Select]
  1.         CASE XPosition1TB ,YPosition1TB, ZPosition1TB ,_
  2.                 XPosition2TB   ,YPosition2TB, ZPosition2TB ,_
  3.                 XPosition3TB   ,YPosition3TB, ZPosition3TB ,_
  4.                 XPosition4TB   ,YPosition4TB, ZPosition4TB ,_
  5.                 XPosition5TB   ,YPosition5TB, ZPosition5TB ,_
  6.                 XPosition6TB   ,YPosition6TB, ZPosition6TB ,_
  7.                 XPosition7TB   ,YPosition7TB, ZPosition7TB ,_
  8.                 XPosition8TB   ,YPosition8TB, ZPosition8TB ,_
  9.                 XPosition9TB   ,YPosition9TB, ZPosition9TB ,_
  10.                 XPosition10TB   ,YPosition10TB, ZPosition10TB ,_
  11.                 XPosition11TB   ,YPosition11TB, ZPosition11TB            
  12.                 IF VAL(Text(id)) >= -5E14 AND VAL(Text(id)) <= 5E14 THEN
  13.                     SetFocus TheQwerkey&(WhichIsIt%(id) + 1)
  14.                 ELSE
  15.                     AA& = MessageBox("Value From -5E14 To 5E14 Required", "", 0)
  16.                 END IF
  17.  

Tidied:
Code: QB64: [Select]
  1.             CASE 3 TO 5, 11 TO 13, 19 TO 21, 27 TO 29, 35 TO 37, 43 TO 45, 51 TO 53, 59 TO 61, 67 TO 69, 75 TO 77, 83 TO 85 'XPosition1TB ,YPosition1TB, ZPosition1TB et cetera
  2.                 IF VAL(Text(id)) >= -5E14 AND VAL(Text(id)) <= 5E14 THEN
  3.                     SetFocus ControlIndex&(CtrlIndex% + 1)
  4.                 ELSE
  5.                     AA& = MessageBox("Value From -5E14 To 5E14 Required", "", 0)
  6.                 END IF
« Last Edit: April 06, 2020, 06:24:56 am by Qwerkey »

Offline TempodiBasic

  • Forum Resident
  • Posts: 1792
    • View Profile
Re: Very Odd Behaviour of Control Object Value
« Reply #12 on: April 06, 2020, 06:10:14 pm »
@Qwerkey
about
Quote
WhichIsIt% was a Function of mine which I used to convert the id numbers into CtrlIndex% which is then used (the program knows what the value of CtrlIndex% is).  Actually, because of tidying up I removed WhichIsIt% (which was only required once after tidying) and put the translation code at the beginning of the SUB in question.

I have no idea of how id is managed into WhichIsIt% but to avoid that fatal change of id you can manage it into WhichIsIt% making a copy of it with which to work
Code: QB64: [Select]
  1. ' in pseudocode
  2. x% = WhichIsIt%(id)
  3. ....
  4. ....
  5.  
  6. FUNCTION WhichIsIt% (id AS LONG)
  7. DIM id_copy AS LONG
  8. id_copy = id
  9. ' here all the action and operations are made on id_copy
  10. ....
  11.  

or you can do this duplication just first to call WhichIsIt% if the id returned is a second value to get back in addition to the result of the FUNCTION

Code: QB64: [Select]
  1. DIM id_copy AS LONG
  2. id_copy = id
  3. x% = WhichIsIt%(id_copy)
  4. ....
  5. ....
  6.  
  7.  

another way is to pass the parameter by value and not by reference. In QBasic the parameter is for default passed by reference but you can force to pass parameters by value using () around each parameter.
here a simple demonstration...
Code: QB64: [Select]
  1. prova = 1
  2. PRINT " Prova        x  "
  3. PRINT prova
  4. x = funzione((prova))
  5. PRINT prova, x
  6. prova = 1000
  7. PRINT " Prova        x  "
  8. PRINT prova
  9. subroutine (prova)
  10. PRINT prova
  11.  
  12. FUNCTION funzione (a AS SINGLE)
  13.     a = a + 5
  14.     funzione = a
  15.  
  16. SUB subroutine (b AS SINGLE)
  17.     b = b + 10
  18.     PRINT , b

in this case you can solve simply adding these two rounded brachets to the id
Code: QB64: [Select]
  1. x%=WhichIsIt%((id))
  2.  

Hoping that this can be useful for you...
Programming isn't difficult, only it's  consuming time and coffee

Offline Qwerkey

  • Forum Resident
  • Posts: 755
    • View Profile
Re: Very Odd Behaviour of Control Object Value
« Reply #13 on: April 07, 2020, 05:55:28 am »
@TempodiBasic Thanks for spending time on this, but there is no need (unless you find interest in this yourself).  The function WhichIsIt% was never the problem, although since Steve McNeill told us that a Function can alter the value of the calling arguments it is always wise to be careful in the ways you suggest.  The problem was the InForm SetFocus call which altered id, even though the code has no indication that this will happen.  The problem was solved by moving the SetFocus until after everything which required id was completed.
(I would usually, in my normal British way, make some reference to my dimness in not being wary of InForm procedures which I do not fully understand, but Pete would become upset!).

Offline TempodiBasic

  • Forum Resident
  • Posts: 1792
    • View Profile
Re: Very Odd Behaviour of Control Object Value
« Reply #14 on: April 07, 2020, 04:56:47 pm »
Ok my oddities aren't in the centre of the issue.
Thanks to read my post.
Good that you've solved the issue.

Good Coding
Programming isn't difficult, only it's  consuming time and coffee