RubberViews 2.00 and 2022R3x : workaround a Xojo bug

I have been made aware of an unexpected NilObjectException happening with the demo program of RubberViews, provided with the unencrypted version.

After some looking around, it appears that dropping a DesktopHtmlViewer on the window disables the Opening and Activated events in that window. Perhaps other controls do that as well.

That prevented the call to init to happen, with as a result, the nilObjectException in SizAll.

I have modified the program, moved the code to App.Opening as workaround.

While I was at it, I noticed RubberViews 2.00 did not handle DesktopContainer. This is now fixed.

All owners of RubberViews 2.00 can download the very latest version I updated, with the download instructions they received upon purchase.


What I noticed was a weird order (on windows). Having both DesktopWindow and DesktopHTMLViewer with Opening() events with System.Debuglog “window” and System.Debuglog “html” respectively, I would expect that any Opening() of any control would ONLY occur after the Window Opening(), as controls needs an existing window to be attached to, but the system is weirdly inverting the order in my machine as I get prints of “html” first then “window”.

As far as I know, this is how it has always operated. Control Open events occur before Window Open.


Makes no sense if we expect “open” as “object created”. Makes sense if it means “object and future child objects created” but it would be weird and we would need something for “object created”.

1 Like

RealBasic as well as Xojo always started creating controls before the Open event in the window. Now Opening. In thatb respect, perhaps it should have been called “Opened”, instead of “Opening”.

1 Like

Or Ready()

The state post-created, post-loaded (open) with all dependent objects created and attached to it and also ready to be used.

Can you replicate a case and report the issue?

1 Like

I intend to. But I will have to drop controls one by one, until the Opening event no longer fires.

My main concern today was to alleviate the issue.


Actually, the issue is trickier than I thought. It is not HTMLViewer that suppresses window opening, but apparently a desktopcontainer.


Well, Robin cannot reproduce the bug…

I checked it myself, though.

It feels like the broken TV that works perfectly when taken to the repair shop.

Maybe there’s a fine difference between both, like OS version, CPU type…
We, the community, had reports of bugs few weeks ago only found in specific Windows machines, that were “newer and faster ones”, that’s how the odd ones were reported… Also, if I do recall correctly, we also had unexpected out of order events from one Intel macOS app after compiled to M1 in one case at least, also few weeks ago.

I tested that on an M1 mini, with both 2022R2 and 2022R3.2. Well…

Well… The R4 is approaching. Let’s see if it fix it.

1 Like