Some Windows users get a NilObjectException when trying to download an update file. Of course, it works fine for me on all my test machines
The update info has been successfully downloaded and presented in a modal window.
As soon as the user clicks the Download button, the error immediately appears.
The Download button disables itself (you can see that thatâs happened) and calls GetFile, where you see Iâve already added a bunch of nil checks:
If f <> nil then
If LblDownloading <> nil then
LblDownloading.Visible = True
If ProgressBar1 <> nil then
ProgressBar1.Visible = True
// Async Send, all results handled by events
UpdateSocket.Send("GET",DownloadURL, f,15) // (last parm is timeout in secs)
Return
Else
MsgBox "ProgressBar is Nil!"
End
Else
MsgBox "Label is Nil!"
End
Else
MessageBox "File "+f.NativePath+" is nil!"
End
Self.Close
UpdateSocket is a URLConnection added to the window in the IDE. It has event handlers for Error, FileReceived, and ReceivingProgressed.
f is SpecialFolder.UserHome.Child(âDownloadsâ) - could this be a permissions issue? I do check for f being Nil, but maybe URLConnection throws an NoE if it canât write?
If the exception was in the code executed by the button I would have expected the button to be listed in the stack trace. However, I have seen a bug logged for stack traces not working correctly when triggered from modal alerts so may be you be hitting that bug and it is excluding some important information.
Are you checking for SpecialFolder.UserHome.Child(âDownloads") being Nil?
Unfortunately, I canât comment on URLConnection as we replaced our comms code with cURL via the MBS plugin.
SpecialFolder.UserHome.Child(âDownloads") is whatâs being passed to GetFile as âfâ, so yes, itâs being checked in GetFile, but as @Andrew_Lambert points out, I then proceed to blithely use f in my MessageBox even if itâs Nil.
This still leaves the question unanswered as to why SpecialFolder.UserHome.Child(âDownloads") would ever be Nil - could it be a OneDrive thing, or a permissions thing, orâŠ? Maybe Desktop would be safer, I dunno. I guess I can always throw up a dialog and let the user choose.
maybe try .Exists first
or use
.TemporaryFile
or path
SpecialFolder.Temporary
your folderitem is something like this?
f=SpecialFolder.UserHome.Child(âDownloadsâ).Child(âUpdate.exeâ)
i am confused why you say it points to Downloads
user have Windows 11^^ i see round edges in screenshot
i would rewrite
Dim path As FolderItem=SpecialFolder.UserHome.Child(âDownloadsâ)
if path = nil then Message
if path.exists then
else
message or create folder
endif
Dim f As FolderItem
f=path.Child(UpgradeFileName)
Windows does give the user an option to relocate the Downloads folder. I donât know how many do this but itâs a theoretical possibility.
It would be nice if there were actually a SpecialFolder.Downloads. Some years ago I read a thread of VB users who were looking for the same thing. With a little help from my friends, I adapted a VB declare to Xojo, which has been so far, so good with me.
Var f as folderitem
Var myID as Ptr=COM.IIDFromString("{374DE290-123F-4565-9164-39C4925E467B}")//"Official" Downloads Folder
Var myCode as Int32
Var myPath as WString
Soft Declare Function SHGetKnownFolderPath Lib "Shell32" (theId as ptr, flags as Int32, ByVal theToken as Int32, ByRef thePath as WString) as Int32
Soft Declare Sub CoTaskMemFree Lib "ole32" (byVal hMem as WString)
myCode=SHGetKnownFolderPath(myID,0,0, myPath)
if myCode=0 then
f=New FolderItem(myPath,FolderItem.PathModes.Native)
end if
//Release the memory. Not sure if I really need to pass a memoryblock instead of WString, but hey, it doesn't crash.
CoTaskMemFree(myPath)
Return f
A small test program sent to him now, however, reveals that while not nil, Downloads does not exist as far as Xojo is concerned, so that any child I designate will be nil.