I have a Pinewood Derby race manager program that has matured over the last 10 years
A couple years ago I added the ability for the program to receive the racers times automatically from the timer via serial communication. At the time I made the addition I never had a problem with windows spontaneously becoming visible. Specifically the Preferences window.
A little background.
The program has the main window where most of the work is accomplished.
To open the Preferences window I added code to the Preferences menu (the application menu) that simply made the Prefs window visible, and when you clicked the Close gadget it made the Prefs window not visible
When I added the original Serial Comm ability I could close the Prefs window and run the rest of the race with the times coming in via serial comm with no problem
This was added in 2015 … several versions of Xojo ago
Today I added another option to the Serial Comm Preferences. And as long as I leave the Preferences window open everything works perfectly.
But if I Close the Preferences window (make it invisible) EVERY TIME the program receives serial input the Preferences window pops back up
I have performed a FIND for PrefsWindow.visible and there are ONLY two places in my whole program. It becomes visible when you select the Preferences menu item, and it becomes non visible when the prefs window Close is clicked. Those are the ONLY two places where the visible property for that window is referenced.
What else could POSSIBLY make that window become visible?!?!
The serial input is handled by a method that parses the input from the timer and stores the times received in the appropriate Lane entries in the main window … so NOTHING in the serial input method references the Prefs Window in any way.
Is there some way that the Preferences menu item is being triggered?
If the window is set to be an implicit instance then any reference to the window (not just .Visible) when it doesn’t exist creates a new instance automatically.
By the way I forgot to mention that this is on a Macintosh computer.
Andrew, once the serial settings are completed the only reference to that window is to read those settings. (and I have no idea what you mean by “implicit instance”) But the window never gets “closed” it continues to exist, it’s just not visible.
Close gadget doesnt CLOSE the window?
Because if it does close the window, any code anywhere that starts
PrefsWindow.someproperty
will cause the window to reappear.
ImplicitInstance ON means you can just start coding PrefsWindow.something and a window will magically be created for you.
Its the way VB used to work.
(Its a property of the window in the design stage in the IDE)
ImplicitInstance OFF means PrefsWindow.visible would fail because PrefsWindow is treated like a class.
You need to specifically create one of these windows with
MyWindow = new PrefsWindow
And after that, you refer to MyWindow.visible and MyWindow.someproperty
If you use MyWindow = new PrefsWindow and leave Implicit Instance turned on,
you get a MyWindow, but if you accidently use PrefsWindow.visible , you end up with TWO windows.
Hardly helpful Ramon - I also disagree about pedantic channel selection. Why do we have the general section then?? Perhaps the General channel could be eliminated completely and we can just post in our relevant OS section.
I personally mainly review the general, windows and getting started channels. I never deliberately look at the MacOS channel. I’ll also look at ALL and if something catches my eye I’ll read it. I looked at this thread because the title was of interest with my own software, and I’ve learned a lot from reading others posts.
What would be much much better is if the forum software allowed us to have a signature. ie. showing the Xojo version, operating system and a general expertise level. That way regardless of erroneous channel postings, one can easily determine what, if any, positive contributions can be made.
[quote=313334:@Steve Kelepouris]Sorry I can’t help you with your issue Marc.
Hardly helpful Ramon - I also disagree about pedantic channel selection. Why do we have the general section then?? Perhaps the General channel could be eliminated completely and we can just post in our relevant OS section.
I personally mainly review the general, windows and getting started channels. I never deliberately look at the MacOS channel. I’ll also look at ALL and if something catches my eye I’ll read it. I looked at this thread because the title was of interest with my own software, and I’ve learned a lot from reading others posts.
What would be much much better is if the forum software allowed us to have a signature. ie. showing the Xojo version, operating system and a general expertise level. That way regardless of erroneous channel postings, one can easily determine what, if any, positive contributions can be made.
I’m really sorry if I sounded not as friendly as I pretended with the emoticon :). As you can imagine, English is not my mother language and finding the correct words is not always easy. I just tried to help, but I see that you go further and I agree with you about channel organization.
Click on the window in the navigator, and click “Inspector” on the right. You will see “Implicit instance” as a switch in the list of properties. Switch it off, then run. I bet you will immediately see where it breaks.
BTW you can change the channel of a thread you started by clicking “Controls” in the upper right corner of the forum conversation, and select “Change channel”. It is always better to place a discussion about Mac in the macOS channel, so people see immediately if the can help.
I would agree, Steve, if the issue is specific to the platform. iOS issues in the iOS channel, Windows issues in the Windows channel, etc. But the General channel is good for questions that are not platform specific, regardless of what platform the coder is on. And Michel is right when he says:
If your issue turns out to be specific to the platform, then you should move the discussion to that channel.
Of course, this is my opinion and your mileage may vary.
Binary thinking, and calling pedant people who try to help is not very nice, is it ?
It is more courteous and more efficient to post in a platform if your issue is there. Insisting on posting on general without any details leads to the usual question "Mac, Windows, Linux ? Tedious.
There are questions that pertain indeed in General : cross platform ones for instance.
Once again, it all resorts to courtesy for the readers, and more importantly, for the few people who try to help. Nothing is more frustrating than to spend time testing and posting a solution for one platform, and get a response such as “Thank you, but I need that for XXX”.
Also; you mention that your application keeps the window open, just visible so that other components can read the settings? I would advise against this.
Instead what I would recommend is creating a Prefs object that handles only the properties.
When the app launches the prefs object reads in the preferences.
When the user opens the PrefsWindow, it reads the values from the prefsObject.
When the user closes the PrefsWindow, it updates the values within the prefsObjects and tells the object to write these settings to disk.
Everything else simply reads the data from the prefsObject.
Sams’ Approach might be the better solution. Always deal with objects and destroy them if not needed anymore. Another aspect could be how you open the Prefs Window. I experienced modal windows as best solution for any kind of preference window. In code it looks like this:
Michael, I switched “implicit instance” off and when I try to Run the program (debugger) it reports 237 errors. Of course that’s EVERYWHERE that I set or change a gadget on the prefs window.
But there are only three places where PrefsWindow.visible is referenced. The first is App.Open line 5 “PrefsWindow.visible = false” which stops the window from showing during the application open process … and the other is in the Menu handler FilePrefs “PrefsWindow.Visible = true” (there is also a "PrefsWindow.show but this is the only place for ‘show’) … the third is in the PrefsWindow close event that says “me.visible = false”
So, Sam, no the window doesn’t stay open all the time. In fact, that’s the problem … I DON’T want it to stay visible all the time. But if I click the Close button (red dot in top left corner) it becomes invisible (as it should), but as soon as the program receives serial data input the window becomes visible again.
Sam, you have my curiosity up about the “Prefs Object” you mentioned. My method of dealing with prefs is that I have the prefs window with all of the various gadgets to select the various preferences … and in the PrefsWindow.close event I call a method that reads the gadgets and saves the settings in a file before the window becomes invisible. Is there a better way to do this? A prefs object that I’m not aware of?
Thomas, while I understand what you are saying, I don’t see how making the window modal would help my problem of it becoming visible when it shouldn’t.
What I said earlier is “If I leave the window visible everything works just fine” but I want to be able to make that window invisible and have it STAY invisible until I invoke the “FilePrefs” menu item.
Jeff, That was an excellent thought and I was sure it would work, but unfortunately, it didn’t.
I changed all three of the visible/invisible statements to PrefsWindow.top statements. The window disappeared as expected, but once again, as soon as the program received serial data the window reappeared.
Interestingly, it did not appear at the position I had programmed … which strongly suggests that the window was being reinstantiated. But I’m still at a loss as to how or why that should be.
Thats exactly what is happening, but weve been saying so all along.
Heres the thing:
Thats NOT what happens.
It closes the window, even if you set the visible=false property.
So the next time you talk to Prefswindow,
Xojo opens it again. Like new. Visible.
The right way to handle that is the prefs class discussed earlier.
Create a prefs class.
Add properties for everything that the prefswindow can display
Create one global instance of that class when you start the app.
Set the properties.
Whenever new information arrives which changes the pref (why would it?), change any property you need to.
When the user asks for the prefs window, just PrefsWindow.showmodal
and update the controls of that window in the Activate event
When the user closes it, update the values of the prefs object in the Close event
Note: when upating controls in an ACtivate event, you need a flag to prevent it happening twice
[code]static bDoneThisALready as boolean
if bDoneThisALready then
else
//set the controls (to the heart of the sun… little Pink Floyd reference there)
bDoneThisALready= true
Add the CancelClose event to your prefs window and put
if appQuitting then
return false // the app is quitting we dont want to prevent that
else
self.hide
return true
end if
in there
That will make it open once, and then when you try to close it it will just hide and no longer be visible
Any time after that when you call show it will become visible
And it wont ever get nil’d and another instance suddenly be created and show up when you dont expect it to
Long terms a “prefs object” that stores all the data is a good idea though
That way you can have access to the prefs data without having to have the window open
The window should just be the UI that allows you to set different data - not the repository for that data while your app is running
This is uncharted territory for me. I’ve never created a class before. But I’ll dig into the docs and see how it goes. You may be hearing from me again.
short term - simply make your existing prefs window hide & show when needed
this lets you move forward today without having a rewrite needing to be done first
long term - creating the class to hold prefs data that your prefs window can show to users
this would let you move away from having all the data just in the Prefs window & its controls & properties & needing to have it open all the time
Before I attempted to create a new ‘prefs’ class I did a search through the code in my methods and discovered two places where I was polling gadgets on the prefs window to determine their settings. So, instead, in the Close of the Prefs Window I put the settings of those gadgets into variables. That way the methods could read the settings from those variables.
Works like a champ. The Prefs Window stays hidden now.
