|
Post by Robert on Mar 7, 2024 11:33:05 GMT -5
George, any guess why the gang has been so quiet? I can't recall when there's been such a long time with essentially no user commentary coming in. Nobody has any questions? Nobody has found any bugs? Nada?
R
|
|
|
Post by Robert on Mar 7, 2024 10:55:15 GMT -5
Yes, LOCATE is a charmer, but it's very useful. It's no wonder it's a challenge, but a worthwhile one.
I seem to recall a developer that had such a distaste for "make-work", and now, he is the one making work for himself. You must have a good reason, I am sure.
Parsers can be fun, the main thing to remember is to be as consistent as possible. That way, you don't "out-clever" yourself and end up creating brand-new bugs.
R
|
|
|
Post by Robert on Mar 6, 2024 16:30:54 GMT -5
Any news? Awful lot of crickets out here ...
R
|
|
|
Post by Robert on Mar 1, 2024 11:38:16 GMT -5
George, that sounds like nature's way of telling you to make notes, and go back and update the doc. Undocumented features = unused features. New users will never know they exist. And, I am about as old a user as you got, and even *I* don't know about those undocumented features. All I really know is what is in the doc. I read the Help and act accordingly.
R
|
|
|
Post by Robert on Feb 29, 2024 17:34:35 GMT -5
I am wondering if this is an opportunity to add any parser-related features that might have been kicked around in the past but had been dismissed because it would have called for a "total rewrite". Now that you ARE doing a total rewrite, this could be your chance.
Thoughts?
===> Here was an idea I had recently that would involve the parser. You now have the concept of MACLIB enabled. Now, suppose you have two MACLIB's, call them AA and BB. Suppose there were different versions of a macro called MYMAC.MACRO, one in both of these libraries AA and BB, and you want to be able to get to either one at will. How?
The idea was to allow a "MACLIB qualifier". Suppose you want the version of MYMAC in library AA or BB. To issue this command on the primary command line, you could say something like this:
AA:MYMAC
or
BB:MYMAC
This would also give you a way to issue qualified macro names from a key-mapped key.
This way, you could 'define' MACLIB's without having to make any particular MACLIB the "default" one to access the macros in that library.
Since you are now working on the parser, maybe this is something you could add, if you thought it was worth doing. Main issue is detecting the "MACLIB qualification" syntax. You might have to do a "look-ahead" checking for:
name1 : name2
and then seeing if name1 was the name of a MACLIB symbol.
R
|
|
|
Post by Robert on Feb 25, 2024 16:24:42 GMT -5
Jo, I have some questions about the macro.
1. It seems you are using the macro to find if the name of the file itself is found within the text of the file. So, you are trying to find "ABC" in file ABC.TXT. Is that right?
2. Since you are going through a list of files in FM and are in a loop, it seems that you will be issuing SPF_Post_Do possibly more than once. I am not aware of this function supporting multiple calls to it before the macro it is in exits. George, could you comment on this? If SPF_Post_Do can be called more than once in a single macro, is some kind of delimiter between calls to it needed, like $CRLF or (Home) (Enter) or something? After all, you could end up issuing multiple FF primary commands in FM. Is that what you intended?
R
|
|
|
Post by Robert on Feb 25, 2024 16:03:10 GMT -5
Jo, could you show the ChkSpfVers.Macro too?
Also, I am puzzled by the final line, Halt(fail,Get_MacName$, "should run as LineCommand")
It seems based on the logic, this line will always execute. It would be more typical to put a check for this much earlier, right after you check for Is_FM, like: If False Is_Line_Cmd then Halt(fail,Get_MacName$, "should run as LineCommand")
R
|
|
|
Post by Robert on Feb 25, 2024 14:02:15 GMT -5
Jo, is your syntax for SPF_Post_Do accurate and correct? If "anytext" is a variable, then unless you did something like,
anytext = "anytext"
then the trace contents of "P=FF anytext" seems unlikely.
If you have 'fudged' the output for privacy reasons, maybe you could rerun with some dummy but actual data.
Not sure if this helps, but maybe it would clarify things.
R
|
|
|
Post by Robert on Feb 25, 2024 11:53:41 GMT -5
George, just in case you missed it, HnD 9 is now available. I know you like to keep current with this.
R
|
|
|
Post by Robert on Feb 23, 2024 11:25:41 GMT -5
Sorry. After posting it, I had a change of heart and deleted it. I am sure what you experienced was merely an invalid link to a post that no longer exists.
|
|
|
Post by Robert on Feb 12, 2024 22:32:18 GMT -5
You asked for a solution, and I gave you what you asked for.
|
|
|
Post by Robert on Feb 12, 2024 16:01:54 GMT -5
Yes, perhaps, "99.9% of users only ever have 1 version installed and running". But does that really mean "in which case all this discussion is moot"?
I think though that your count of 99.9% could be a bit off. After all, you are constantly creating beta versions, and only intermittently release a prod version. So, anyone keeping up with, and using, beta versions will likely have at least two versions installed - the current prod and the latest beta. (Personally, I have least 20 prior beta versions, but generally only try to use the latest one.) I believe it would be more accurate to say that "99.9% of users only ever have TWO versions installed" and may have or or both of them running.
It would be a different matter if beta versions were only used by internal testers - which is the normal definition of a "beta version" in software houses - but for SPFLite, basically all of us are beta testers. In reality, the only meaningful difference - for users - between beta and prod is that "prod" means you have revised the Help doc.
I run with "1 SPFLite" set. If I click on my Beta icon, I currently get 24.037. Now, if I happened to be in Windows File Explorer, right click on a text file and click on, "Open with SFPlite", I get a second instance of SPFLite, in this case it's the prod version 24.026, because that's what the file explorer context thing is defined as - it only runs SPFLite2.exe. So, I now have two versions running, even though I asked for only one. It seems to me that the prod version should have detected that a beta was running, and because I said to run only one, it should have directed the request to the currently running beta. That is what I would view as "1 SPFLite". And, I will add, I *AM* in the 99.9% that only runs one (or, tries to, anyway).
That's why I see this as NOT moot. I only want one, but I can't stop it from running two. I feel the part about things being this way for years is not accurate either, because you have done a lot of work on Instances in the last year, and as I recall there actually WAS some hue and cry about it.
But, since you bring up the OPEN* command bringing up new instances, I looked up the Help for this, and basically ALL it says about what happens is ONLY contained in the title of the Help: "OPEN - Open New SPFLite Instance and Edit File". Otherwise, you don't document it AT ALL, anywhere, as far as I can tell. That also means that the "Only 1 SPFLite running" option was never implemented consistently. The documentation for THAT says,
"If this box is checked, multiple executions (separate instances) of SPFLite will be prevented. If you attempt to open a file in a second SPFLite, it will detect the existing one running and cause your file to be opened as a new tab within the existing SPFLite execution. Once that is done, the second SPFLite will go away (actually, you will never even see it). Even when this option is set, a new SPFLite instance can still be opened by issuing an OPEN primary command from the existing SPFLite."
So, OPEN is "immune" from being under the control of this General Option flag. And, externally starting an SPFLite is ALSO immune from being under control of that flag, if the versions differ. That being the case, just what is under the control of this flag? It seems like you ignore this flag far more often that you respect it. That is the basic problem I have: When checked, multiple executions will be prevented, except when they aren't prevented - which seems to be the majority of the cases. Thus, "One 1 SPFLite running" is all but meaningless. If you are so reluctant to actually support this option, maybe what you really want is to remove it and have totally unrestricted multiple executions going. I hope you don't, but I'd rather have the option removed than to have it respected inconsistently.
But yes, we definitely need to hear from other users.
|
|
|
Post by Robert on Feb 12, 2024 14:15:52 GMT -5
George, I will try to respond to this as best I can. Truly, I don't want an argument, which is where I see this heading.
First, my apologies if I misapplied the word 'broken'. However, if I ask for only one SPFLite to run, and I can easily get two running, what word would you use instead of 'broken'?
You want a solution? Allow me to offer one. The main issues here are:
(1) "one SPFLite running" doesn't actually mean TRULY one instance.
(2) sometimes version numbers matter when allowing multiple instances, and sometimes they don't.
(3) I will go out on a limb and say that running multiple instances is an unusual, non-typical usage. That is true for all editors, not just SPFLite. Thus, any options that involve multiple-instances should be considered as an EXCEPTION, and not the usual behavior.
To resolve this, and to give you what you need as well as what a typical user needs, I would do this:
In the general options GUI, the [x] Only 1 SPFLite running would be renamed as [x] Allow multiple SPFLite's running
Here, this would invert the sense of the [x] checkbox. Then, add a second checkbox: [x] Allow multiple SPFLite's only for unique version numbers
Finally, a "beta" version would always be considered (internally) as different from any "prod" version. For purposes of your code making a version comparison, it would be AS IF a prod version had a ".0" appended to the number, and a beta version had a ".1" appended to it. This is ONLY how the code would treat it; users would NOT see .0 or .1 displayed anywhere.
If the "unique versions" is NOT enabled, then your test would simply be if ANY version of ANY SPFLite exe was running or not.
I believe this would support all of the known use cases as I understand them.
R
===> I believe it would be helpful, if you added the new checkbox, to rearrange general options screen so the two options are placed next to each other. I know redoing GUI code is a pain, but it would make the most sense to keep them together.
===> There's one other thing. Suppose I start one version, then try to start another version, and multiple SPFLite's is not allowed? You would either have to permit the "mis-use" of multiple SPFLite's or not. You could either dismiss the second instance and just not run, or you could show a popup that said "You requested to run a second SPFLite but your general options do not allow for it. Do you want to allow the second instance for this time only? Yes / No". Something like that. And yes, adding a potential popup would be (for you) another annoyance, but I see it as a protection for users. Maybe they had a good reason to limit things to one exe only, and this would prevent them from possibly making some kind of mistake that could put their data at risk. If they really want multiples running, they can ask for it and make it 'official' by changing the options gui.
|
|
|
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
|
|
|
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
|
|