Build gives Class NilObjectException

I am forced to use a 3rd Party Plugin to resize my project main window for smaller pc graphic resolutions to make my software more marketable. I know have a resizable Windows build that works in debug and it builds with no errors. I use the setup factory installer application that creates a perfect working Windows build without the resize plugin. I am testing the resize windows build on another computer that installs ok without any errors.

When I launch the program the window launches then a modal error dialog red circle with x shows - An exception of class NilObjectException not handled. The Application must shut down. I thought the error was possibly due to a missing .dll file in the installer. I checked multiple times and it is not the problem.

The Xojo documentation for App Class has a paragraph showing App can return Nil

The App function will return the global application object only after it has been registered with the runtime.
That means that any operations which happen before this registration process cannot rely on App returning non-nil.

Is this the problem that is the cause my error?

If it is what do I have to change to correct this problem?

The 3rd party plugin runs a loop to resize the window in the open event in the subclass main window of the 3rd parties resize window superclass.

I dont follow why a plugin is necessary

Have you contacted the maker of that plugin ? He should be able to assist…

Norman so you are saying I don’t have to buy a 3rd party plugin to make my project over sized window resize to the resolution of the user. Please enlighten me if there is a different way. I was led that I have to purchase a plugin like Elastic Windows, Rubber Views to achieve these results.

If you have a few controls on a window, the locking mechanism may be enough. You will have to manage the content, though.

An autoscale class such as RubberViews spares you the work.

I don’t think those are actual plugins. More like 3rd party classes.

Indeed, neither Elastic Window nor RubberViews are plugins.

Do you have Project --> Break on Exceptions Checked? Perhaps you can trap it down to the line that is causing the NOE. Usually its a reference to a class that is not instantiated. Can you post the line it breaks on?

Sorry 3rd party classes, I always thought it was the same thing (shows how much I know.) I am kind of dumping my frustrations here and I apologies.

Hey Mike - Yes Break On Exception is checked. The NOE does not show up at all in the debug in Xojo. The program works perfectly there.

Do you see any # Pragma’s that might not be allowing code to show up in your debug build vs. compiled for windows which shows you the NOE?

Where would I find the # Pragma’s? Would I have to setup a Break Point somewhere to see it?

I would do a search in the IDE for #TargetWin32 (if that is the target I understand you are targeting and failing vs. debug IDE). You might be able to flesh code hiding behind these pragmas.

Yes I’m am using #TargetWin32. Here is the code and this is the Main Window (frmGAmain) Open Event Handler that is a subclass to the Elastic Window superclass. This might be the spot where the problem lies

Dim H As Integer
Dim W As Integer
Dim PreAspectRatio As Double
Dim WinW As Integer
Dim WinH As Integer

H = Screen(0).Height
W = Screen(0).Width

PreAspectRatio = frmGAmain.Width/frmGAmain.Height

 // Turn On Elastic Windows Resize Mode

frmGAmain.ResizeMode(ElasticWindowResizeMode.Window)

#If TargetWin32 Then
#If DebugBuild Then
frmGAmain.Height = 646 // Debug to test a smaller window size
frmGAmain.Width = 1009
#Else
//Test if Window is oversized and if it is reduce size Height 122 Pixels and calculate width from ratio
If frmGAmain.Height > H Then
WinH = H - 122 ’ WindowHeight (768 - 122)
WinW = WinH * PreAspectRatio
frmGAmain.Width = WinW
frmGAmain.Height = WinH
End If
// Same as above with oversize Width then Calculate Height from ratio
If frmGAmain.Width > W Then
WinW = W - 15
WinH = WinW/PreAspectRatio

    frmGAmain.Width = WinW
    frmGAmain.Height = WinH
  End If
  
#EndIf

#ElseIf TargetMacOS Then
'OS-X Program
#EndIf

OH you resize the controls on the windows based on the screen size !!!
Now I see why you se third party code

Perhaps Try allowing the code that runs in #DebugBuild also run in Target32. This should give you parallel testing for IDE and Win32 builds for testing this bug out.

//#If TargetWin32 Then
//#If DebugBuild Then
frmGAmain.Height = 646 // Debug to test a smaller window size
frmGAmain.Width = 1009
//#Else
//Test if Window is oversized and if it is reduce size Height 122 Pixels and calculate width from ratio
If frmGAmain.Height > H Then
WinH = H - 122 ' WindowHeight (768 - 122)
WinW = WinH * PreAspectRatio
frmGAmain.Width = WinW
frmGAmain.Height = WinH
End If

//#EndIf

I’ll try that - Thanks Mike

Good luck and hopefully it will narrow it down for you.

FWIW if Elastic Window had reached an impasse showing in that bug, and knowing that Christian may not support it anymore, I am providing a drop-in replacement with RubberViews called RubberWindow.

Just drop the RubberViews classes in the project, and make the super of your windows RubberWindow instead of ElasticWindow.

While compatible with Elastic Window, RubberWindow uses RubberViews original engine, that probably does not exhibit the same issue.

You can download a fully functional evaluation package at http://fontmenu.com/xojo/RubberViewsTrial.zip

Like EW, it just displays a MsgBox if no license number is entered, but everything works like the complete package.

Mich I puchased the full unencrypted source code version already from you. I’ll try it as you describe as above. Thanks I’ll try it that way

I do appreciate your support. The EW drop-in replacement has been added at the end of July. You may want to download the latest version (use the download instructions you received upon purchase).