|
Post by Stefan on Feb 9, 2024 4:05:17 GMT -5
George,
Note: This may be just another manifestation of meuh's 7th Feb post in the 'Suggestion - A thought about managing SPFLite updates' thread
but it isn't fixed yet
OPTIONS - GENERAL - Only 1 SPFLite Running is ticked
SPFLite is not running.
In File Explorer... (1) Right-click on any .TXT file and select OPEN WITH and specify "SPFLite2 Editor" An instance of SPFLite starts and opens the file in a tab (2) Right-click on another .TXT file and select OPEN WITH and specify "SPFLite2 Editor" Another instance of SPFLite starts and opens the file in a tab
This shouldn't happen. The current official release does this correctly, i.e. the second file is opened in another tab of the same SPFLite instance as the first file.
|
|
|
Post by Robert on Feb 9, 2024 10:26:36 GMT -5
I thought that when you open using windows file manager, the "context entry" for SPFLite has a fixed EXE name, which is "the" production name of it, not any beta which might exist. For me, I have dozens of betas in the Program Files folder, but when I open a text file like you did, I get the prod version 24.026.
Which version do you get when you do this?
R ===> I see that you do things differently than I do. There is a thing George made to set up a registry entry, so that you can see "Open with SPFLite" as a context entry (without the 2 suffix), which is different than you do. You got your entry the 'hard way' by first doing an Open With, then (at some point) locating SPFLite2.exe in Program Files (x86) then picking the EXE.
I re-tried doing it your way, and I only get one EXE running, not two. Something doesn't add up here.
|
|
|
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 Stefan on Feb 9, 2024 12:38:39 GMT -5
I thought that when you open using windows file manager, the "context entry" for SPFLite has a fixed EXE name, which is "the" production name of it, not any beta which might exist. For me, I have dozens of betas in the Program Files folder, but when I open a text file like you did, I get the prod version 24.026. Which version do you get when you do this? R ===> I see that you do things differently than I do. There is a thing George made to set up a registry entry, so that you can see "Open with SPFLite" as a context entry (without the 2 suffix), which is different than you do. You got your entry the 'hard way' by first doing an Open With, then (at some point) locating SPFLite2.exe in Program Files (x86) then picking the EXE. I re-tried doing it your way, and I only get one EXE running, not two. Something doesn't add up here. Robert,
Sounds like George has this well in hand.
I have a similar setup to you, only in reverse. I just right-click in File Explorer and choose OPEN WITH and then 'SPFLite Editor'. This refers to and executes SPFLite2.EXE from folder C:\Program Files (x86)\SPFLite2\
WHen the first beta appears, I rename the 'official Release' version to SPFLite2Rlse.EXE and save the latest beta with the normal SPFLite2.EXE name in the same folder. SO by defualt I alsway launch the beta but I also have a separate (yellow) SPFLite icon that lets me specifically start the SPFLite2Rlse.EXE.
The only other thing is that, years ago, I placed a shortcut to "C:\Program Files (x86)\SPFLite2\SPFLite2.exe" into folder C:\Users\Stef\AppData\Roaming\Microsoft\Windows\SendTo\.
But on Windows 11, the File Explorer 'right-click' menu no longer includes 'Send To' without a diversion via the 'Show more options' entry, so I tend not to do use 'Send To' any more these days.
|
|
|
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 Stefan on Feb 9, 2024 15:20:21 GMT -5
George,
Are you sure that's all it is?
When I have no SPFLite instance active and load the first file as described, the beta version instance is started to open the file.
I then repeat the process for another file and another instance of the same beta version is started to open that file. Both instances have the same version identification in their windows' title bars.
The second file should have opened a second tab in the first SPFLite instance.
|
|
|
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 Robert on Feb 9, 2024 15:53:24 GMT -5
George, I would like to offer some well-meaning advice. I believe that your current test for an existing SPFLite running is being too 'precise'. I think the correct thing to do is to see if ANY version of SPFLite - beta or prod - is running, then that satisfies the test. Version numbers and beta/non-beta should not be part of the test.
That is the safest way to do it.
R
|
|
|
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 Robert on Feb 9, 2024 17:40:19 GMT -5
Can you tell me if the precise process how single vs. multiple instance thing is handled? You now tried to explain it, and yet I still don't understand. The thing you say you want to avoid, I would avoid too. There seems to be a fundamental misunderstanding here.
Could you spell this out for us in plain English? What is going on seems vague, and I find it disconcerting.
R
|
|
|
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 Robert on Feb 10, 2024 11:38:10 GMT -5
George, the decision point "Same exact version/Beta status" is what I have an issue with. If you read about "Only 1 SPFLite running" in the Options - General Help, this decision point is not documented.
I believe you changed this logic some time back, and didn't make a fuss about it, not that I recall. I feel that what is currently implemented is misleading. We can check "Only 1 SPFLite running", but there can still be more than one, as long as each executable has a unique version and beta status.
Basically, your logic effectively has an option like this:
[x] Allow multiple unique SPFLite instances to run
Only, the "[x]" is permanently turned on and we can't disable it. I would disable it, if I could.
I wish this worked differently. Here is a proposed change. Let's say the question were changed from a checkbox to a dropdown box. Then, there would be a new entry like this:
Allow multiple instances of SPFLite to run [dropdown]
In the dropdown, there would be 3 options: No Yes Yes, for unique SPFLite versions
This would allow users to control how this gets handled. Here, "versions" would be documented to mean the combination of version number and beta status. However, in practical terms, beta status doesn't really need to be checked for, as long as you never create a beta version and a prod version with the same version number. So far, I don't think you've ever done that, right?
R
|
|
|
Post by Robert on Feb 10, 2024 11:56:01 GMT -5
Here's a thought about prod vs. beta:
Suppose you changed the way you are showing "beta" notation on the title bar.
Instead of using the literal "Beta", you add a 4th number to the version number. For "prod" versions, the 4th number would be 0, and for betas, it goes from 1 up. That way, it allows for cases where bugs are flying fast and furious, and there might be more than one beta on a the same day. It provides a consistent notation that is easy to distinguish and to test for in your code. And, there would be no more A and B betas. Just one, simple, consistent number for everything.
So, if you create a prod version today, it would be 3.0.24041.0 and the first beta version today would be 3.0.24041.1 with additional betas today being 3.0.24041.2, 3.0.24041.3 and so on.
R
|
|
|
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 Robert on Feb 11, 2024 11:24:29 GMT -5
George, I understand your reluctance to change the numbering scheme, even if it would make things consistent.
But, right now, if I say "only 1 SPFLite running", and I click on the prod icon I have on the desktop, and then I click on the beta icon I have, sure enough, I get TWO SPFLite executables running. Quibble all you want about beta vs. non-beta, but two programs running is TWO programs running, not 1. On that basis, the "only 1 SPFLite running" is failing to enforce that runtime option. When I say one, I mean ONE, not two.
Leave well enough alone? Sure, but this isn't well enough. It's broken.
R
|
|