Microsoft Windows Permissions

I have a user who gets a NilObject Exception when he tries to launch my app. In order to track down the problem, I’ve created a version of the app that in creates a text file on the user’s desktop to which event info is to be logged during the launch process. Now the app reports an I/O Exception on launch, presumably because it can’t create or write the log file, which I’m guessing is maybe a permissions issue.

Is there a location for which I can be sure of having write permission? The app’s folder?

I would try one of the following:

you could log the messages and put them into a window listbox, from there a dialog to save as.
usually desktop is writetable. or maybe the file is still in use or open somewhere.
i had the case that a pdf viewer block a file until the display was closed.

Thanks, ahmma try ApplicationData, as I use that for prefs already, generally with success.

Except that the app crashes during launch with the NilObject Exception I’m trying to track down, so I’d probably never get far enough to do that.

Does Windows have an equivalent of the Console messages?

You would have to use DebugView

1 Like

That looks cool, but I don’t know how I’d use Windows system debug info to find the problem with my Xojo code :slight_smile:

1 Like

If you use System.DebugLog to write out debug messages you can see them in the macOS Console or the downloadable DebugView / DebugView++ on MS-Windows.

Ah, I see, thanks, good to know!

It might be worthwhile considering adding a debug / logging mode to your application which writes diagnostic information.

This is a summary of what we do:

  1. We have a debug mode property which is set to false and is flipped to true if at startup our app detects the presence of a file with a specific name in the same folder as the executable.

  2. We have a debug message function which accepts a string as a parameter and calls System.DebugLog if the debug property is true.

  3. Our code contains lots of calls to our debug message function with useful information.

What this means is that we can deploy our application with the ability to capture diagnostic messages by adding a dummy file and re-launching. This obviously only works if you have already added logging to the correct areas but this naturally builds up over time.

That’s exactly what I’m doing, except that I’m writing to a text file instead of System.DebugLog, as locating and sending a text file is easier for non-technical users than trying to use DebugView.

ah - okay. I thought you might be just creating a one-off hacked version of your app with logging for this customer. We did that a few times and eventually realised it was easier to keep it in all of the time and have a method to switch it on and off.

1 Like

because you can not write to desktop, maybe you can not open a sqllite database at start or something that a folderitem returns nil?
see also app event UnhandledException, its possibe to let a app open until a error (theoretical)

I’ve changed the destination for the log file to a subfolder of ApplicationData, but it still throws an IOException (number 123) on launch, which almost certainly is triggered by my trying to create and write to the log file (which definitely does not already exist).

It works fine on my own test machines (as did writing to the desktop, I think). Is there some security setting in Windows which could be preventing my app from writing to local storage on one particular user’s machine? Could it be related to the location of the executable (which I’m guessing is his downloads folder at present)?

Check the filename and path something seems invalid. Check the string and hex codes inside of it.

Dim d As DateTime
d = DateTime.Now
Dim logfilename As String = "My App Log "+d.ToString(Locale.Current, DateTime.FormatStyles.medium, DateTime.FormatStyles.medium)+".txt"
LogFile = New FolderItem(SpecialFolder.ApplicationData.Child("My Client").Child(logfilename))
Dim outstream As TextOutputStream =  TextOutputStream.Create(LogFile)
outstream.WriteLine "Log file created"

In the debugger there are colons delimiting the time fields, but under MacOS they get automagically converted to forward slashes and it works; under Windows I assume colons are OK or they get converted there as well - in any case it works under both platforms for me, so I don’t think that’s the issue.

ApplicationData.Child(“My Client”) exists.

Yeah, that was it. I changed the filename to

"My App Log "+ReplaceAll(d.SQLDateTime,":",".")+".txt"

and it works, thanks!

1 Like