Feedback Reporting of FolderItem Assignment failure

General
1

I’m interested in being able to report this problem explained here in Feedback and I would like to be able to explain it when I report it.
I am horrible at organizing things. It’s taken me years to be able to explain this to myself.

This problem all revolves around my preferences fileS and 3 windows and how the file is saved and accessed. I don’t know if access is part of the problem.

The line that causes the problem is a RE-assignment of a folderitem

 ThPrefsF = ThColl.Child("PrefsFile.ini")

The windows are StrtUpPrefs, Preferences, MainList.

  1. StrtUpPrefs controls which set of files are accessible as in various preferences and data files. It is also the first window to be opened.

  2. Preferences manages various preferences but can also open StrtUpPrefs. It can only manage one set of Preferences at a time. The close of this window under these circumstances opens the MainList window. The saving of this Preferences file does not cause a reopening of the Preferences file.

  3. MainList is a window that enables access to the data / exercise files. It also allows access to its preferences.

The only time this happens is when the preferences file is saved, but the MainList is NOT accessed.
The order of Windows for not having a problem is:
StrtUpPrefs >> MainList >> Preferences (File modified) >> MainList.

The order for causing the error is:
StrtUpPrefs >> MainList >> Preferences (File modified) >> StrtUpPrefs. Error is now caused on the close

I have this set of lines of code with folderItems that cause different platform errors but consistently cause errors of assignment.
The order of windows which are related to this error(s) is possibly part of the error.
The code:

ThColl = PFolderProp//IniFolder.Child(titPthLdArray(PthLIndex)) If ThColl.Child("PrefsFile.ini") <> Nil And ThColl.Child("PrefsFile.ini").Exists Then ThPrefsF = ThColl.Child("PrefsFile.ini")//Failure on this line

ThColl and PhPrefsF are global folderItems in a module and not shared, and not in App.
The particular code is in a window and in the close event. PFolderProp is a property of the window.

The line which causes a problem is ThPrefsF = ThColl.Child("PrefsFile.ini")
ThColl is the Parent folder and gets reassigned properly.

ThPrefsF is the location of an ini file.
ThPrefsF is interestingly only a problem if it has been saved (not accessed?) and the StrtUpPrefs and the ThColl is changed and therefore the ThPrefsF is then accessed instead of MainList.

I hope I’ve explained HOW the setup for the error is made.

Now for the error on ThPrefsF = ThColl.Child("PrefsFile.ini")

Under all circumstances the assignment is NOT reapplied.

On Mac this causes a crash of the debugger. The line isn’t finished.

On PC the ThPrefsF becomes Nil.

Suggestions on how to report this and what could be the problem???

2

Still very unclear.

Question: Why do you have several preferences files?
if you have a global property of type folderitem, you can assign it when the app opens.
You affect your internal variables as your app operates.
At any time, and/or when the app closes, you save your internal variables into the one and only preferences file.

It shouldnt be hard to keep prefs for different types of window apart even if they are in one file.

I dont know what you are saving, but lets guess it is ‘last used window width’

Store

StrtUpPrefs_width Preferences_width MainList_width

in your one and only prefs file.

Then when you next start the app, read them in and use the ones you need.

3

I have different preferences because each different set has its own set of Folders it can access, scores it keeps, fonts used, field titles, etc. If you want to look at something less complicated try Download/cnet.com for language learning and maybe add in Flashcards.

The preferences file has nothing to do with window positions.

I have about 5 thousand cards to work with, and theirs is probably a couple hundred.

4

I filed 2 bug report 53130 and 53129. One per OS. This is for the basic problem of the debugger crashing.

5

The example only has 2 NOEs. I still haven’t a clue what you see.

6

What is NOE??
About what I see. If you go to inspect either of the variables, the debugger crashes.

7

[quote=402524:@Arthur Gabhart]What is NOE??
About what I see. If you go to inspect either of the variables, the debugger crashes.[/quote]
NOE = NilObjectException

8

Could you be more specific? “Crashes” means different things to different people and I’m not clear as to what your definition is yet. Please describe exactly what you are doing in the debugger and exactly how the IDE reacts.

Or better yet, take a video of it happening and let us see it!

9

OH yeah. NOE. There is no NOE.

The debugger literally disappears. If the debugger crashes, the app being debugged disappears. I also get the warning from Apple saying “Do you want to restart the app”

I’ll work on a video. I’ve never done one before.

Sorry that I wasn’t more clear on the bug report. I’m often editing what I wrote. I also learned the word is watch and not inspect

If you “watch” the rcntItems FolderItem on the second time it is assigned, the debugger crashes.
Here’s a link to the XMLPFOpen

What I am trying to do is find out if a FolderItem was ever reassigned.

10

Okay, did some more testing. To have the code work correctly the example needs to be placed in the Documents folder. Even for an example this is a bad idea.

Then there is no NOE but also no crash. Mojave, Xojo 2018r1.

11

Thanks. Hadn’t thought about where it goes. Yes in the Documents folder.
I guess that means people usually debug from something like Programs (PC).
I didn’t think the OS would allow that.

The OSs I tested on are XOJO 2018r2. High Sierra and Windows 10. Something like this has been going for a while.

I also didn’t think it I could produce a crash that easily. It usually doesn’t crash that easily.

Also. You have to literally watching the FolderItem and inside the RcntItems FolderItem which is inside Module1.
If it is outside of that, it will correctly re-assign.

12

Further clarification. You have to step through to get it to crash.
If you just resume, it’s assigned correctly.

Further clarification, if it changes any FolderItem property and I watch it, and step through the assignment, it crashes.