|
Post by George on Feb 23, 2024 10:52:58 GMT -5
Robert: I got notified of your post, but I can't access it; it says I'm 'not authorized' - ?? - but I'm an administrator, so ...
Does it look normal to you? Can you still access it?
George
|
|
|
Post by George on Feb 13, 2024 12:24:59 GMT -5
Robert: I did a quick check, the option for 'only one SPFLite' has been around for over 10 years, and multiple Instance support for almost 5 years. And we've never had so much as a comment (good or bad) from users about the 'problems' you want solved.
George
|
|
|
Post by George on Feb 12, 2024 16:18:53 GMT -5
My basic response is the same, when I hear a 'hue and cry' from the users that what we have is causing them problems, I will 'do something', until then, I still say this is a 'make work' project.
George
|
|
|
Post by George on Feb 12, 2024 14:46:00 GMT -5
Robert: It's not quite that simple. Multiple instances, regardless of the Options setting can always be created by using the OPEN/OPENE/OPENB/OPENV commands.
Users can also have unique Instances opened, so as well as versions, we also have Instance names and the Beta/non-Beta condition.
It all gets messy in the code, as well as the testing, and as I said, it has been like this for years and I don't hear a huge hue & cry from users to 'make this messy condition better'.
I'd like to hear from users (other than you) who feel this area needs addressing, because I just don't see the need. I'm sure 99.9% of users only ever have 1 version installed and running, in which case all this discussion is moot.
George
|
|
|
Post by George on Feb 11, 2024 14:06:42 GMT -5
OK then, other than turning OFF 'Only one SPFLite running', give me a solution for how I test new versions while having the production version 'up' doing useful work.
And that solution also has to let me test the 'Only one SPFLite running' logic.
Yes, I know, I could put in some arbitrary code to do this, which I would have to edit and set on and off as needed, a royal PITA.
Also "Broken?" And just how does what is done currently 'break' anything? Other than violating the exact legal phrasing of the Options ON/OFF text, it 'breaks' nothing, at most it is an annoyance. And I'm sorry, but Beta testers, by their nature, have volunteered to put up with some annoyances in order to help development.
This is simply a tempest in a teapot.
George
|
|
|
Post by George on Feb 10, 2024 14:08:19 GMT -5
Sorry Robert: No. Your suggestion is simply a make-work exercise. Besides, I prefer the "Beta" addition over another numeric level. It stands out, users probably have no interest/knowledge of a numbering system where the last digit means "Beta" if it's non-zero. Seeing "Beta" is as clear as day to anyone.
The current code has been like this for a very long time, running without incident. It only came to our attention after the change you requested to have "Beta" added to the title bar, and I slipped up and introduced an error.
If I hadn't missed a simple 1 line change in the test for unique instance, it would have continued along, just as before, without incident.
Also, I certainly don't want to go about changing version numbers during the day just because it's 'busy'. My #RESOURCE version Include file is created automatically for me overnight by a scheduled task which executes a small Basic program to update this file.
This Pgm would also need tweaking, yet more nuisance work.
Let's leave well enough alone.
George
|
|
|
Post by George on Feb 10, 2024 10:52:32 GMT -5
Robert: OK, I'll try it again. Note: The method of starting SPFLite makes absolutely no difference; Icon, Context Menu, Cmd line, etc.
Start SPFLite session 1 | | | Start SPFLite Session 2 | | | Is "Only 1 SPFLite running" set? | | | Yes --------------> Is there another Instance running? | No | | | | | +<-----------------------------No | | Yes | | | | | Same exact version/Beta status? | | | | +<-----------------------------No | | Yes | Continue Execution | | | +< Open in new tab <---------------------------Send Open Data to the 1st running instance | | | | Continue Execution Terminate
|
|
|
Post by George on Feb 9, 2024 16:12:18 GMT -5
Robert: No, I disagree. I run with 'single instance', but when I'm testing, I don't want my test versions 'handing off' to any old production SPFLite session I might also have running. I think the test with the full version is just fine for 99% of users. Such users typically don't have multiple versions running.
George
|
|
|
Post by George on Feb 9, 2024 15:49:32 GMT -5
Stefan: I don't think the latest Beta has the fix for properly handling this problem. I'll push out a new Beta, then maybe this will all settle down.
George
|
|
|
Post by George on Feb 9, 2024 15:13:33 GMT -5
Robert: Well. AUTONAME defaults to NONE, which means the AUTO file is = to the Profile name.
Which is the same as AUTOFILE = * (And I don't remember why we added the *, isn't NONE sufficient?)
Otherwise, the AUTOFILE name is whatever is specified, and it better exist.
George
|
|
|
Post by George on Feb 9, 2024 12:47:22 GMT -5
Robert: The problem wasn't the context menu, regardless of how started, the first thing an executing instance does (if only one instance is selected) is to look around and see if the same instance is already executing (including being the same VERSION).
If an equal Instance is found, it sends a message to that previously running version to 'take over' the open, and then it shuts itself down.
It was failing because of the newly added .Beta to the windows title bar, it treated it as being different.
George
|
|
|
Post by George on Feb 9, 2024 11:24:07 GMT -5
Clive: Reported. Try the latest Beta, there's a fix in there for the problem.
George
|
|
|
Post by George on Feb 9, 2024 11:22:17 GMT -5
MUEH spotted this. It doesn't look just at the EXE name, but the version as well. As per Roberts suggestion that Beta releases should 'say so' in the Window title bar, I missed allowing for that in the code that looks for an existing instance running.
That's been fixed, but hasn't made it to Beta yet.
George
|
|
|
Post by George on Feb 7, 2024 9:50:26 GMT -5
MUEH: There's always an interaction you don't think of.
Fixed.
George
|
|
|
Post by George on Feb 7, 2024 9:38:27 GMT -5
Stefan: Yes, the whole way messages were handled was revised. Previously, if a message is waiting, the next display refresh puts it out and deletes it. If the display gets refreshed again (tab switch etc.) you end up with nothing.
I altered it so the clearing of the message does not occur until the next real activity in the tab occurs (KB, mouse). So a screen refresh will keep displaying the message till you DO something.
George
|
|