Strange Issue with wxRadioButon/Box

BlitzMax Forums/Brucey's Modules/Strange Issue with wxRadioButon/Box

Pete Rigz(Posted 2016) [#1]
I have a very strange issue with radio buttons, where by they're not unselecting as you select each one, so they all end up looking like they're all selected. Functionality wise they are working ok so it seems it's a display issue. Trouble is I can't isolate the issue, if I create an example app with a radio button it works fine. I have no idea what is different in TimelineFX that might be causing it. It's only happening in el capitan, mountain lion was fine on my old mac, and windows is all good too.

Any idea how I could go about debugging this? Or where I might look in the wx module?


Henri(Posted 2016) [#2]
Hi,

problems happening on platform that I have no access to are hard to give an advice, but couple of things you could try:


1.
Try changing creation flags for radiobutton to see if it makes any difference.

2.
Is radiobutton attached to sizer ? if you unattach it does it make a difference ?
What if you create a sizer just for the radio group ?
Any bitmaps in same parent ? If it's an graphical glitch refreshing window might
show this.

3.
Check from https://github.com/maxmods
that you are running newest version.


-Henri


Derron(Posted 2016) [#3]
WX from 2.9.4.0 to 2.9.5.0 fixed some issues with radio button groups ...


If you are able to select multiple RB without deselecting the other ones, they might not belong to the same "radio button group" (first one has to get style/flag "wxRB_GROUP").

From the docs: wx.mod/wxradiobutton.mod/wxradiobutton.bmx:

You can create a group of mutually-exclusive radio buttons by specifying wxRB_GROUP for the first in the
group. The group ends when another radio button group is created, or there are no more radio buttons.




Did you use the groups style?


bye
Ron


Pete Rigz(Posted 2016) [#4]
This is with the latest checkout from git. The code in the program hasn't changed for a few years now and has always worked fine, it's just since the upgrade to el capitan.

Some of the things I've tried that haven't made a difference:
- forcing a refresh of the window.
- Using set value to force them to toggle off
- Using wxRB_SINGLE and manually setting them instead of exRB_GROUP.

It happens with wxRadioBox as well.

I do use bitmaps elsewhere in the tab so i'll try disabling those to see if it makes a difference. It must be due to a combination with something else as like I say, isolating in a separate app to test doesn't recreate the issue.


Derron(Posted 2016) [#5]
Think as long as you are not able to provide a "sample" reproducing the bug, you are on your own.

Dunno how "modular" your code is, so you might easily disable certain things in your app until the bug is gone.

Maybe Brucey is able to update to the latest wxWidgets-variant on github and the bugs are gone. I just checked the last 3 months on the git commits of wxwidgets but while scanning the logs I did not find something useful (hard to find if you do not know what keywords a dev would use :-)).


bye
Ron


Henri(Posted 2016) [#6]
Did you try creating a new sizer just for the radiobuttons ?

-Henri


Pete Rigz(Posted 2016) [#7]
Problem solved! it was due to the fact that I'm rendering a graphics context at 60fps. The main problem being that I have timer that ticks every millisecond, I guess it was stopping the radio boxes from being redrawn. I needed it to tick at that rate otherwise it suffered a lot of stuttering in the preview window, however it doesn't seem to do that anymore so I can get away with a lower tick rate which fixes the problem.

I've kind of recreated the problem here with the glmax2d example, except it does manage to redraw them after a delay I guess because there's less stuff going on (In timelinefx they all end up being selected and not unselecting at all). I made it render 3 times every tick to show the issue more - if it is an issue. It does work fine on windows though. Click the radio buttons quickly to see it happening.




Derron(Posted 2016) [#8]
Where does "wx.wxglmax2D" come from? Seems you use an older wxMax.


I adjusted it to use the current revisions:


Changes:
- see "imports"
- SetGraphics Self.CanvasGraphics()

But running results in an error (seems "Samples/glcube.bmx" does it similar - and fails similar):
./bmk makeapp -t console -quick -r -x "testcodes/wxlag.bmx"
[ 96%] Processing:wxlag.bmx
[ 98%] Compiling:wxlag.bmx.console.release.linux.x86.s
flat assembler  version 1.68  (32768 kilobytes memory)
3 passes, 29315 bytes.
[100%] Linking:wxlag
Executing:wxlag
The program 'wxlag' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
  (Details: serial 29 error_code 9 request_code 14 minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)


commenting the "render" functionality, the app starts, so something with the GL canvas is bugging out the app.


bye
Ron


Pete Rigz(Posted 2016) [#9]
Ahh yes I forgot about that, I think Brucey removed wxglmax2d at some point so I did have to put it back because I still use it (apart from that though it is the latest wx). Why I still use it though I can't remember as it's been a few years, there is a reason though!


Derron(Posted 2016) [#10]
So you mixed "new" and "old" ...dunno if this is flawed then already.

older wxWidgets lead to some debug messages in the console, so an update is nice to have - albeit "3.1" (which is what Brucey uses) is not stable.


Next to wxglmax2D you of course also use another wxglcanvas.mod then (the current one has the wxGLGraphics commented out - maybe for some reason?).

Nonetheless I created an issue for this on github, so Brucey might tackle it somewhen in the future.


bye
Ron


Pete Rigz(Posted 2016) [#11]
Yes I did have to uncomment those as well. I shall have to try and make it work without needing glmax2d, then I'll probably find out why I needed it, although it wouldn't surprise me if it's not necessary anymore.

Thanks for taking a look anyway.


Derron(Posted 2016) [#12]
Try the following:



I replaced some portions in your code - it now uses the standard wxmax2d.mod



Just the changes (diff):



Pete Rigz(Posted 2016) [#13]
Ok, so i found out why I use glmax2d :)

I had a go at using wxmax2d but looking in that module I notice that it doesn't actually use gl or dx rendering at all, it uses a DC context which isn't any good for particle rendering as it's basically software rendering. This also means that standard functions in max2d like setclsolor don't work as they're all remmed out in the driver.

@Brucey: was their a specific reason this was changed like this? It's no biggy really as I can just use the wxglmax2d.mod which I still have and edit wxglcanvas to uncomment everything so it works with the standard max2d commands. Be nice if it was in there officially though, unless i'm missing something!


Brucey(Posted 2016) [#14]
Hallo :-)

Does this work for you?


Note we are extending wxGLCanvas.
Also note how the Canvas is created, that wxGLCanvas already handles OnPaint (we just need to override the OnPaint method), and SetGraphics calls the wxGLCanvas method CanvasGraphics().
This is using the built-in brl.glmax2d (as it should really).

Basically all we are doing is setting up a GL context with wxGLCanvas - glmax2d shouldn't care how we've done that. It just wants something to draw on.

This is a better implementation as it uses the stuff already available, rather than copying and replicating a whole bunch of functionality.


Pete Rigz(Posted 2016) [#15]
Yes that does work!

I was extending wxglcanvas but i was using wxmax2d not brl.glmax2d which is a bit daft, thought I was missing something :)

Thanks!