Author Topic: [InForm] incompatibility Inform vs QB64 Variable naming rules  (Read 21758 times)

0 Members and 1 Guest are viewing this topic.

Offline TempodiBasic

  • Forum Resident
  • Posts: 1792
    • View Profile
[InForm] incompatibility Inform vs QB64 Variable naming rules
« on: August 29, 2018, 06:16:07 pm »
Hi Fellippe

while I'm trying to get an alternative method to manage input keyboard to the goal (calculator) of Terry
I have fallen in this issue...

If I set Caption of a Button like a number.... Inform has coded that number as name of a variable LONG for ID of that item.
But as soon as the code (.BAS) is loaded in QB64 ide it halts me with warning Invalid variable name on line....

Here is .BAS

Code: QB64: [Select]
  1. ': This program uses
  2. ': InForm - GUI library for QB64 - Beta version 7
  3. ': Fellippe Heitor, 2016-2018 - fellippe@qb64.org - @fellippeheitor
  4. ': https://github.com/FellippeHeitor/InForm
  5. '-----------------------------------------------------------
  6.  
  7. ': Controls' IDs: ------------------------------------------------------------------
  8. DIM SHARED Numbers AS LONG
  9. DIM SHARED PressNumberButtonLB AS LONG
  10. DIM SHARED PressedNumberButtonLB AS LONG
  11.  
  12. ': External modules: ---------------------------------------------------------------
  13. '$INCLUDE:'InForm\InForm.ui'
  14. '$INCLUDE:'InForm\xp.uitheme'
  15. '$INCLUDE:'Numbers.frm'
  16.  
  17. ': Event procedures: ---------------------------------------------------------------
  18. SUB __UI_BeforeInit
  19.  
  20.  
  21. SUB __UI_OnLoad
  22.  
  23.  
  24. SUB __UI_BeforeUpdateDisplay
  25.     'This event occurs at approximately 30 frames per second.
  26.     'You can change the update frequency by calling SetFrameRate DesiredRate%
  27.  
  28.  
  29. SUB __UI_BeforeUnload
  30.     'If you set __UI_UnloadSignal = False here you can
  31.     'cancel the user's request to close.
  32.  
  33.  
  34. SUB __UI_Click (id AS LONG)
  35.     SELECT CASE id
  36.         CASE Numbers
  37.  
  38.         CASE PressNumberButtonLB
  39.  
  40.         CASE PressedNumberButtonLB
  41.  
  42.         CASE 1BT
  43.  
  44.         CASE 2BT
  45.  
  46.         CASE 3BT
  47.  
  48.         CASE 4BT
  49.  
  50.         CASE 5BT
  51.  
  52.     END SELECT
  53.  
  54. SUB __UI_MouseEnter (id AS LONG)
  55.     SELECT CASE id
  56.         CASE Numbers
  57.  
  58.         CASE PressNumberButtonLB
  59.  
  60.         CASE PressedNumberButtonLB
  61.  
  62.         CASE 1BT
  63.  
  64.         CASE 2BT
  65.  
  66.         CASE 3BT
  67.  
  68.         CASE 4BT
  69.  
  70.         CASE 5BT
  71.  
  72.     END SELECT
  73.  
  74. SUB __UI_MouseLeave (id AS LONG)
  75.     SELECT CASE id
  76.         CASE Numbers
  77.  
  78.         CASE PressNumberButtonLB
  79.  
  80.         CASE PressedNumberButtonLB
  81.  
  82.         CASE 1BT
  83.  
  84.         CASE 2BT
  85.  
  86.         CASE 3BT
  87.  
  88.         CASE 4BT
  89.  
  90.         CASE 5BT
  91.  
  92.     END SELECT
  93.  
  94. SUB __UI_FocusIn (id AS LONG)
  95.     SELECT CASE id
  96.         CASE 1BT
  97.  
  98.         CASE 2BT
  99.  
  100.         CASE 3BT
  101.  
  102.         CASE 4BT
  103.  
  104.         CASE 5BT
  105.  
  106.     END SELECT
  107.  
  108. SUB __UI_FocusOut (id AS LONG)
  109.     'This event occurs right before a control loses focus.
  110.     'To prevent a control from losing focus, set __UI_KeepFocus = True below.
  111.     SELECT CASE id
  112.         CASE 1BT
  113.  
  114.         CASE 2BT
  115.  
  116.         CASE 3BT
  117.  
  118.         CASE 4BT
  119.  
  120.         CASE 5BT
  121.  
  122.     END SELECT
  123.  
  124. SUB __UI_MouseDown (id AS LONG)
  125.     SELECT CASE id
  126.         CASE Numbers
  127.  
  128.         CASE PressNumberButtonLB
  129.  
  130.         CASE PressedNumberButtonLB
  131.  
  132.         CASE 1BT
  133.  
  134.         CASE 2BT
  135.  
  136.         CASE 3BT
  137.  
  138.         CASE 4BT
  139.  
  140.         CASE 5BT
  141.  
  142.     END SELECT
  143.  
  144. SUB __UI_MouseUp (id AS LONG)
  145.     SELECT CASE id
  146.         CASE Numbers
  147.  
  148.         CASE PressNumberButtonLB
  149.  
  150.         CASE PressedNumberButtonLB
  151.  
  152.         CASE 1BT
  153.  
  154.         CASE 2BT
  155.  
  156.         CASE 3BT
  157.  
  158.         CASE 4BT
  159.  
  160.         CASE 5BT
  161.  
  162.     END SELECT
  163.  
  164. SUB __UI_KeyPress (id AS LONG)
  165.     'When this event is fired, __UI_KeyHit will contain the code of the key hit.
  166.     'You can change it and even cancel it by making it = 0
  167.     SELECT CASE id
  168.         CASE 1BT
  169.  
  170.         CASE 2BT
  171.  
  172.         CASE 3BT
  173.  
  174.         CASE 4BT
  175.  
  176.         CASE 5BT
  177.  
  178.     END SELECT
  179.  
  180. SUB __UI_TextChanged (id AS LONG)
  181.     SELECT CASE id
  182.     END SELECT
  183.  
  184. SUB __UI_ValueChanged (id AS LONG)
  185.     SELECT CASE id
  186.     END SELECT
  187.  
  188. SUB __UI_FormResized
  189.  
  190.  
  191.  

So, to continue in my coding I must rename the name of items (in this case of Buttons)

theorically the MakeNameOfItem of InForm, that usually makes name equal to Caption of the item, could have a flag option like CaptionName (that I find very useful) and StandardName (that was NameItemNumberItem i.e. Label1). And if CaptionName is active the MakeNameOfItem could check if the first character is ok or add in lowercase the item string (i.e.  1BT becomes bt1BT,  1LB becomes lb1LB) like I have done manually in this example that I'll post for another issue in another thread.

Thanks to read and to try
Programming isn't difficult, only it's  consuming time and coffee

FellippeHeitor

  • Guest
Re: [InForm] incompatibility Inform vs QB64 Variable naming rules
« Reply #1 on: August 29, 2018, 06:47:06 pm »
I tried to foolproof the autonaming routine but that case escaped me. I will review it before the next beta is released, thanks for reporting.

FellippeHeitor

  • Guest
Re: [InForm] incompatibility Inform vs QB64 Variable naming rules
« Reply #2 on: August 30, 2018, 01:45:31 pm »
I went on to try to replicate the error with InForm's editor and I'm baffled, TempodiBasic.

When I try to change the caption of a button to "1", the autoname feature renames the control as "BT", not "1BT".

Then I went on to try to manually rename the control (not the caption) to "1BT". InForm didn't let me.

My question is: How were you able to name those controls with a number as the first character?
« Last Edit: August 30, 2018, 01:52:52 pm by FellippeHeitor »

FellippeHeitor

  • Guest
Re: [InForm] incompatibility Inform vs QB64 Variable naming rules
« Reply #3 on: August 30, 2018, 02:58:24 pm »
Went back to Beta 6 and couldn't reproduce the issue either. Please let me know how to reproduce it as soon as you can.

Offline TempodiBasic

  • Forum Resident
  • Posts: 1792
    • View Profile
Re: [InForm] incompatibility Inform vs QB64 Variable naming rules
« Reply #4 on: August 31, 2018, 04:22:45 am »
Hi Fellippe

1. Thanks for time and attentions to my communications
2. You are right and so I'm right :-) Win-Win
 2.1 Why? If you try to rename the item_control starting with a number You cannot do this!
 2.2 If you do like me: renaming the item_control starting with & because I want that the number is a Hotkey to press button, now yu get my results.

Dear Fellippe I attach a image file with result and InForm version

Good Coding
NamingRules1.jpg
* NamingRules1.jpg (Filesize: 347.21 KB, Dimensions: 1366x768, Views: 626)
Programming isn't difficult, only it's  consuming time and coffee

FellippeHeitor

  • Guest
Re: [InForm] incompatibility Inform vs QB64 Variable naming rules
« Reply #5 on: August 31, 2018, 07:16:02 am »
Ah! Mystery solved. Thank you!