My license was good thru 2019 r3. But 2016 r1 has been rock solid (until now) for me and met all my programming needs. Michel Bujardet (I dearly miss him and the knowledge he shared with us on this forum) used to use 2016 r3 for the same stability reasons.
So check if things work in 2016r3 as you still have access to it.
Thanks for that, Tim. Just so happens thatās what Iām working on changing to right now.
If you do not need GDI+ drawing I would recommend 2019r1.1
2019r2 and 2019r3 are the baby API 2.0 releases with ambiguously confusing support for both.
2020r1 was Web 2.0
2022r2 was the last usable API 2.0 IDE.
2022r3 introduce a ridiculous timer to the code editor that Xojo should be ashamed of and everything has been downhill since.
Good idea, Rick (Duh, why didnāt I think of that ). I think Iāll go out to the website and download that from the legacy archive and give it a spin.
Thanks, Tim ⦠think Iāll give that a try if 2016 r3 doesnāt do the trick.
Just donāt trust in its 64 bit capabilities (compilation for 64 bit target). I remember flaws. Keep it 32 bit until 2019. From 2016r4+ until 2019 we had lots of nasty problems, many tied to 64bit and DirectX if I remember correctly.
Interesting idea, Julia. Iāll try that along with popup menu and see which one appears more user friendly to my client. Thanks for your suggestions!
Is 2019 r3 64-bit?
Optionally. End of 2016 was when we started being able to produce Windows 64.
The 2019r1.1 (and r3) IDE is 64 bit, so by that time the ābeta phaseā of 64 bit had been worked out.
Thanks to you and Rick for clarifying that for me.
If 2016r3 solves your problem, go for it and ship your request. After the end of hurry, check Timās great considerations because things changed over those years, and you may need touch here and there. I do remember that I got UIs needing redesign due to loss of transparency for example.
A thought:
(which could be way offā¦)
if you are using the Action eventā¦
Does it fire is there is no change?
A radiobutton, despite being called a button , is a two state control, in conjunction with other radiobuttons with the same parent.
If it is ON, and it is the only radio button, and you click it, the state wonāt change.
If there are 2 such buttons on the same window, only one of them will be true.
Clicking the other one will swap their states, and thats when I would expect an Action event to occur.
They do NOT need to be a control set for this to occur - they can be different names.
So do two radiobuttons work when they are children of the window?
Do they still work when they are children of a groupbox?
Thanks for jumping in, Jeff
Nope ⦠it does not fire and there is no change
Nope ⦠tried that with no result
Nope ⦠I have multiple instances within the program that use radio buttons on a Group Box that work just fine. Itās when I put those radio buttons and groupbox in this moveable modal window that gets launched that they donāt operate at all.
Try letting the cell click event finish and using the following to test:
// Where LaunchWindow is a method that opens your child window
Timer.CallLater( 0, LaunchWindow )
That will at least tell you if it is the ListBox code that is causing your issues.
Iāll give it a go, Ian ⦠thx!
If 2016r3 does not fix your problem, you could save a copy somewhere and strip out everything except the bare-bones (listbox with a clickable cell that opens a window with radio buttons that do not work) able to show the problem and share with us. We can try to find the cause and a fix or workaround.
I donāt know if thatās possible here, Rick. The program is probably on the order of ~ 10,000 lines of code or more. There is so much interaction between things, that stripping out something in almost any part of the program will render other parts not functional. I did create a separate project with only a main window with a listbox and the launch window with the radio buttons (essentially the exact same thing and same code as is in the full project) and it worked just fine. That tells me itās something in the full project causing the issue ⦠but even if I could strip out most of the surrounding trappings, my fear is that whatever is the root cause might disappear with the stripped items ⦠and subsequently adding them back one at a time to narrow things down would take an immense amount of time and effort. The program also uses a multitude of plug-ins from MBS to piDog to Einhugur and more which would make it impossible for anyone who didnāt have those plug-ins to test even a stripped down version.
That makes things hard for sure. Well, good luck finding workarounds.