EventGadget() = -1 when using default text in StringGadget()

[Derren]

Hey guys, I'm a bit perplexed by this weird behaviour.

For some reason EventGadget() is -1 upon opening the window when I set a default text for any of the StringGadgets. That causes a compiler error with SetGadgetColor() for example. Does anyone know why?
I reproduced this behaviour with the example from the help.

Code: Select all

; Shows possible flags of StringGadget in action...
  If OpenWindow(0, 0, 0, 322, 205, "StringGadget Flags", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
    StringGadget(0, 8,  10, 306, 20, "Normal StringGadget...")
    StringGadget(1, 8,  35, 306, 20, "1234567", #PB_String_Numeric)
    StringGadget(2, 8,  60, 306, 20, "Read-only StringGadget", #PB_String_ReadOnly)
    StringGadget(3, 8,  85, 306, 20, "lowercase...", #PB_String_LowerCase)
    StringGadget(4, 8, 110, 306, 20, "uppercase...", #PB_String_UpperCase)
    StringGadget(5, 8, 140, 306, 20, "Borderless StringGadget", #PB_String_BorderLess)
    StringGadget(6, 8, 170, 306, 20, "Password", #PB_String_Password)
    Repeat 
    	event = WaitWindowEvent()
    	If event = #PB_Event_Gadget ;imho, should not fire before the gadgets are created, seems to fire upon setting the text for a gadget
    		Debug EventGadget()
    	EndIf 
    	
    Until event = #PB_Event_CloseWindow
  EndIf

Did I do something wrong? Or am I expected to check if EventGadget is greater than -1 before I use functions like SetGadgetColor()?
I mean it's not like I called EventGadget() before checking if a #PB_Gadget_Event occured.

[uwekel]

I think it is a bug as gadget numbers are always positive. This problem does not exists on Linux Fedora 20 x86.

[TI-994A]

… EventGadget() is -1 upon opening the window when I set a default text for any of the StringGadgets

Hi Derren. It seems that the WM_NCPAINT and WM_ERASEBKGND messages (likely triggered by setting the default text) are slipping through during the creation of the child windows, just before their handles are returned to PureBasic. Not sure if this is a bug though.

…am I expected to check if EventGadget is greater than -1 before I use functions like SetGadgetColor()?

That shouldn't be necessary, as PureBasic functions would target gadgets by their assigned gadget numbers.

...This problem does not exists on Linux Fedora 20 x86.

This could be because the Linux messaging system differs from Windows.

[uwekel]

…am I expected to check if EventGadget is greater than -1 before I use functions like SetGadgetColor()?

That shouldn't be necessary, as PureBasic functions would target gadgets by their assigned gadget numbers.

It is necessary, otherwise you get a "Gadget does not exists" error.

[Derren]

It's easy enough to fix with an If, I just thought it's weird. Especially since it only "misfires" when you use a default text, which makes me think that it's a bug...

[TI-994A]

…am I expected to check if EventGadget is greater than -1 before I use functions like SetGadgetColor()?

That shouldn't be necessary, as PureBasic functions would target gadgets by their assigned gadget numbers.

It is necessary, otherwise you get a "Gadget does not exists" error.

Hi uwekel. The fail-safe is in the fact that gadget numbers can't be negatives, effectively disqualifying those events. If only the valid gadgets are targeted, such errors shouldn't occur.

Even then, this might very well be an unexpected behaviour that the team might wish to resolve.

[TI-994A]

...That causes a compiler error with SetGadgetColor() for example.

It's easy enough to fix with an If, I just thought it's weird...

Hi Derren. Would you mind posting an example where you receive the compiler error?

[Derren]

Code: Select all

; Shows possible flags of StringGadget in action...
  If OpenWindow(0, 0, 0, 322, 205, "StringGadget Flags", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
    StringGadget(0, 8,  10, 306, 20, "Normal StringGadget...")
    StringGadget(1, 8,  35, 306, 20, "1234567", #PB_String_Numeric)
    StringGadget(2, 8,  60, 306, 20, "Read-only StringGadget", #PB_String_ReadOnly)
    StringGadget(3, 8,  85, 306, 20, "lowercase...", #PB_String_LowerCase)
    StringGadget(4, 8, 110, 306, 20, "uppercase...", #PB_String_UpperCase)
    StringGadget(5, 8, 140, 306, 20, "Borderless StringGadget", #PB_String_BorderLess)
    StringGadget(6, 8, 170, 306, 20, "Password", #PB_String_Password)
    Repeat
       event = WaitWindowEvent()
       If event = #PB_Event_Gadget ;imho, should not fire before the gadgets are created, seems to fire upon setting the text for a gadget
       	
       	;If EventGadget() > -1 ;-Fix
       		SetGadgetColor(EventGadget(), #PB_Gadget_BackColor, Random($FFFFFF))
       		
       	;EndIf 
       	
       EndIf
       
    Until event = #PB_Event_CloseWindow
  EndIf

Now get rid of the default text:

Code: Select all

; Shows possible flags of StringGadget in action...
  If OpenWindow(0, 0, 0, 322, 205, "", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
    StringGadget(0, 8,  10, 306, 20, "")
    StringGadget(1, 8,  35, 306, 20, "", #PB_String_Numeric)
    StringGadget(2, 8,  60, 306, 20, "", #PB_String_ReadOnly)
    StringGadget(3, 8,  85, 306, 20, "", #PB_String_LowerCase)
    StringGadget(4, 8, 110, 306, 20, "", #PB_String_UpperCase)
    StringGadget(5, 8, 140, 306, 20, "", #PB_String_BorderLess)
    StringGadget(6, 8, 170, 306, 20, "", #PB_String_Password)
    Repeat
       event = WaitWindowEvent()
       If event = #PB_Event_Gadget ;imho, should not fire before the gadgets are created, seems to fire upon setting the text for a gadget
       	
       	;If EventGadget() > -1 ;-Fix
       		SetGadgetColor(EventGadget(), #PB_Gadget_BackColor, Random($FFFFFF))
       		
       	;EndIf 
       	
       EndIf
       
    Until event = #PB_Event_CloseWindow
  EndIf

[IdeasVacuum]

Well stranger still, if

Code: Select all

While WindowEvent() : Wend

is inserted before the Repeat loop, all is well......

[TI-994A]

Hello again Derren. Would it be prudent to implement any code in the messaging loop without first inspecting the EventType()? If it is processed, the error would not occur:

Code: Select all

If OpenWindow(0, 0, 0, 322, 225, "StringGadget Flags", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
  StringGadget(0, 8,  10, 306, 20, "Normal StringGadget...")
  StringGadget(1, 8,  35, 306, 20, "1234567", #PB_String_Numeric)
  StringGadget(2, 8,  60, 306, 20, "Read-only StringGadget", #PB_String_ReadOnly)
  StringGadget(3, 8,  85, 306, 20, "lowercase...", #PB_String_LowerCase)
  StringGadget(4, 8, 110, 306, 20, "uppercase...", #PB_String_UpperCase)
  StringGadget(5, 8, 140, 306, 20, "Borderless StringGadget", #PB_String_BorderLess)
  StringGadget(6, 8, 170, 306, 20, "Password", #PB_String_Password)
  Repeat
    event = WaitWindowEvent()
    If event = #PB_Event_Gadget
      Select EventType()
        Case #PB_EventType_Focus
          SetGadgetColor(EventGadget(), #PB_Gadget_BackColor, RGB(255, 200, 200))
        Case #PB_EventType_LostFocus
          SetGadgetColor(EventGadget(), #PB_Gadget_BackColor, RGB(255, 255, 255))
      EndSelect
    EndIf
  Until event = #PB_Event_CloseWindow
EndIf

Even if it were a bug, it is circumvented by simply sticking to the coding conventions.

[uwekel]

Even if it were a bug, it is circumvented by simply sticking to the coding conventions.

Howsoever, if a #PB_Event_Gadget is fired, the EventGadget() function must return a valid value.

[TI-994A]

Howsoever, if a #PB_Event_Gadget is fired, the EventGadget() function must return a valid value.

You're right on that point!

[Derren]

Hello again Derren. Would it be prudent to implement any code in the messaging loop without first inspecting the EventType()? If it is processed, the error would not occur:

Unfortunately that is not exactly true. A content change will still fire as the default text is set.
This is closer to my original code where I wanted to detect a change, then get the text from the Gadget and analyse it. But for simplicity's sake I the code I posted above illustrated the main issue as well I think.

Code: Select all

If OpenWindow(0, 0, 0, 322, 225, "StringGadget Flags", #PB_Window_SystemMenu | #PB_Window_ScreenCentered)
  StringGadget(0, 8,  10, 306, 20, "Normal StringGadget...")
  StringGadget(1, 8,  35, 306, 20, "1234567", #PB_String_Numeric)
  StringGadget(2, 8,  60, 306, 20, "Read-only StringGadget", #PB_String_ReadOnly)
  StringGadget(3, 8,  85, 306, 20, "lowercase...", #PB_String_LowerCase)
  StringGadget(4, 8, 110, 306, 20, "uppercase...", #PB_String_UpperCase)
  StringGadget(5, 8, 140, 306, 20, "Borderless StringGadget", #PB_String_BorderLess)
  StringGadget(6, 8, 170, 306, 20, "Password", #PB_String_Password)
  Repeat
    event = WaitWindowEvent()
    If event = #PB_Event_Gadget
      Select EventType()
      	Case #PB_EventType_Change
      		;If EventGadget()>-1
      			SetGadgetColor(EventGadget(), #PB_Gadget_BackColor, RGB(255, 200, 200))
      		;EndIf 
        Case #PB_EventType_LostFocus
          SetGadgetColor(EventGadget(), #PB_Gadget_BackColor, RGB(255, 255, 255))
      EndSelect
    EndIf
  Until event = #PB_Event_CloseWindow
EndIf

[mestnyi]

Code: Select all

Procedure  EventTypeEx()
  If IsGadget(EventGadget())
    ProcedureReturn EventType()
  EndIf  
 ProcedureReturn -1 
EndProcedure
Macro EventType()
 EventTypeEx()
EndMacro

The problem is eventtype it should not be triggered if eventgadget returned -1

[Derren]

Good solution, thank you!

I guess the "correct" way would be

Code: Select all

;...
Case #PB_Event_Gadget
  Select EventGadget()
    Case 0
      Select EventType()
        ;... lots of redundant codes here
      EndSelect
    Case 1
      Select EventType()
        ;... and there... And for every other gadget
      EndSelect
  EndSelect