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”.
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”.
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”.
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.