|
|
Post by Stefan on Apr 24, 2022 5:19:46 GMT -5
George,
Entered on the command line, the CREATE <somefilename>.<some-unknown-filetype> will display the "Create New Profile INI" pop-up panel to solicit a profile name for the unknown file-type. In normal processing this is fine, because user can click <CANCEL> and the file is created using either the DEFAULT or the existing file's profile values (I can't recall which it it, and doesn't matter for now)
However, if the above CREATE command is issed from a macro, it does 2 things:
(1) There's a long delay (2) The 'macro looping' pop-up appears and pretty much immediately the "Create New Profile INI" panel appears
Reply to the 'New Profile' panel first and then reply to the 'Macro looping' panel and all is usually well. But reply to the 'looping' panel first and SPFLIte will become unresponsive and needs to be terminated via Task Manager.
I'm wondering if the 'profile' dialog should appear at all when WRITing a new filetype.
To contain meaningful values (EOL, LRECL, etc, etc), user must either have already amended the current file's PROFILE settings to reflect the new file-type's requirements OR (more likely), wants them to be the same as the current file. On the rare occasion that user needs to adopt another existing profile, chances are they started by editing a file of that profile! Either way, you can just create the new file-type profile with the settings from the current edit session.
Suggestion: Change CREATE (and presumably REPLACE too) so that, when called from a macro, it just creates the file using the values from the existing file's profile, INSTEAD of displaying "Create New Profile INI" panel, which requires user intervention.
Also,... for info, the behaviour for SAVEAS is slightly odd - it presents the 'New profile' dialog and if you click <CANCEL> it presents it the dialog AGAIN!. Click <CANCEL> again and this time it 'believes' you.
Also,also... The 'New Profile' panel describes the <CANCEL> option as 'Cancel file open'. However, in this use case (file creation) the file is still created it just won't build a PROFILE for it.
|
|
|
|
Post by George on Apr 24, 2022 9:18:58 GMT -5
Stefan: I'll have a look. Any macro which knows it may possibly trigger a pop-up should really issue SPF_Loop_Check(off). Whether the pop-up is from some thinBasic function, or an SPF macro call. The loop timeout for macros is only 10 seconds, it's not hard to exceed that with even small, simple pop-ups, let alone the Profile missing dialog. And once the Loop Detect cuts in, you're right, it doesn't always continue properly, and I've no idea why, if it's ignoring the loop it just issues an EXCEPTION_CONTINUE_EXECUTION RC to Windows.
George
[UPDATE]
Had a quick peek. It'll take some time, Profile handling is messy and I don't want to change anything till I dig in a bit more.
[/UPDATE]
|
|
|
|
Post by Stefan on Apr 24, 2022 9:59:58 GMT -5
It shouldn't be tooo hard using the XF macro sample included with SPFLIte to scan the CFG file and check if a profile exists for any given file type.
But I still think that such POP-UPs should perhaps be suppressed during Macro execution (and some defaults used). Imagine the mess if the CREATE comamnd were issued within a loop in the macro to create several new datasets. Alternatively, (as mentioned above in blue), consider if the pop-up really serves any purpose in a CREATE or SAVEAS scenario? Why wouldn't one just use whatever profile is in effect at the time the command is issued and create a new profile entry using those values? The pop-up should really only be necessary IF the user started with NEW i.e. completely empty, edit session and no reliable Profile info is available. Even then, all the user can do is identify another profile as a 'template' or reply <CANCEL>. No opportunity to specify different EOL or LRECL settings, etc.
Most CREATEs or SAVEAS command are issued beacuse the user started with another file of the type they want. In this case, the Profile is already known. |
|
|
|
Post by George on Apr 24, 2022 12:31:40 GMT -5
Been experimenting. If I suppress the pop-up asking for a Profile choice, and create the file using the current data's profile, we end up creating a file which STILL has no profile, so the next time it is chosen to open, the popup appears again. I'm not sure that's an improvement.
e.g. editing A.TXT and say CREATE A.XYZ.
Should it save the data using TXT profile, and create an XYZ Profile copied from the TXT profile?
Should the pop-up have yet another option to create the new Profile from the running profile?
Profile handling is just soooo messy.
George
|
|
|
|
Post by George on Apr 24, 2022 14:33:13 GMT -5
Robert: The problem is that the routine that sets the Profile, is called from a variety of places. What with EDIT/BROWSE/VIEW, CREATE/REPLACE, SAVEAS, COPY, MEDIT, CLONE, etc. there is just not a simple way of handling this. Then add in whether the driving routine is a command line, or an FM line command, and it just gets a bit ridiculous.
Profiles seem like a simple thing to manage, but they aren't.
George
|
|
|
|
Post by George on Apr 24, 2022 15:58:06 GMT -5
Robert: You know, I have to think hard about all this, it's just not easy any more to figure out all the implications. The brain is just getting 'fuzzy'.
The option of having the PROFILE command have 'additional operands' to override the basics of NEW or COPY is really a problem, as it means the command must now parse and process a very long list of possible operands.
I just don't think I'd want to tackle that, nor do I think users would ever type in a PROF COPY profname xxx = AAA, bbb = ccc etc.
George
|
|
|
|
Post by Stefan on Apr 25, 2022 1:34:35 GMT -5
Been experimenting. If I suppress the pop-up asking for a Profile choice, and create the file using the current data's profile, we end up creating a file which STILL has no profile, so the next time it is chosen to open, the popup appears again. I'm not sure that's an improvement. e.g. editing A.TXT and say CREATE A.XYZ. Should it save the data using TXT profile, and create an XYZ Profile copied from the TXT profile? Should the pop-up have yet another option to create the new Profile from the running profile? Profile handling is just soooo messy. George
So let's simplify it a bit.
Short answer - you build the new XYZ profile, populated from the profile settings/values actually in effect for the edit session at the time the CREATE/SAVAS is issued. Don't just copy the old TXT profile because the user may have changed settings deliberately for the new file type before issuing the command.
A pop-up when I open a new file-type for the first time is expected. A pop-up when I write a (to me already existing file but with a new EXTension) is not.
99.99% of the time, I want it to be the same as the one 'model' file which which I began the edit.
There's two parts to this. (1) I appreciate that to write a new file-type, you need to know the file's charactristics - EOL, LRECL, encoding, etc. I contend that yuou can safely obtain those from the file already being edited and used as the 'model/source' of a CREATE or SAVEAS.
If the characteristics for the current file are not the same as those required for the new type, the pop-up doesn't help much anyway because it only requests a profile NAME not the settings. The user must either change the 'model.source' profile settings BEFORE issuing the CREATE/SAVEAS, or change the new Profile afterwards, or point it at an existig profile which has the right characteristics. The pop-up only performs the 3rd option, but in that case, why wouldn't the user begin the whole process using a 'model/source' file with the right characteristics to start with?
(2) You want to save a new profile NAME for SPFLite. You can do that anyway, just don't pop-up the panel. Call it the same name as the file extension.
A macro is not supposed to require user-intervention 'under the covers' (i.e. without the user expecting this).
Failing that, the user must create a profile for the new file type BEFORE the macro is started.
My main issue was that the CREATE was issued in an EMACRO and SPFLIte. And there's not a lot of intervention expected at that stage.
|
|
|
|
Post by George on Apr 25, 2022 8:54:27 GMT -5
Guys: I'm reluctant to muck around in Profile handling, it has been a mine field for years.
Stefan: you don't seem to want any pop-ups when in macro mode, and an automatic Profile creation from the running parameters (not a Profile Copy). That means no bulk copy, but an individual pickup of however many Profile variables there are (40-50 ?)
Correct?
George
|
|
|
|
Post by George on Apr 25, 2022 10:05:53 GMT -5
Robert: Stefan didn't want a copy of the current Profile's CFG data, but a copy of the running values, which, if the Profile is locked, could be significantly different from the stored CFG values.
Providing a function to copy a CFG Profile is trivial, but not what is wanted here.
I'm not aware of any thinBasic event handler type support, kinda tricky with an interpreter.
George
|
|
|
|
Post by George on Apr 25, 2022 13:13:02 GMT -5
Robert: Sounds hard, but with Copy/Paste and finding just the right spot, it's fairly easy.
At the point where is discovers the PDQ profile is missing, and where it would normally popup the Default dialog, it checks to see if we're in macro mode (a simple IF), and then Copies the DEFAULT Profile to PDQ Profile (this is just to get SQL to populate a new table, and it's a 1 line call to SQL.CopyTable) and then does the series of SQL.UpdateStringDirect(ProfNameSQL, "AutoBkup", FORMAT$(AutoBkup)) calls.
George
P.S. Answered your email
|
|
|
|
Post by Stefan on Apr 25, 2022 16:57:58 GMT -5
So, he wants to something like? 1. Open file ABC.TXT which causes a TXT EMACRO to get launched 2. Temporarily modify the TXT profile 3. CREATE XYZ.PDQ 4. Have SPFLite detect that there is no profile for PDQ 5. Create profile for PDQ out of thin air, using the *modified* values in the TXT profile - which is locked, so that the current values and the permanent config values are NOT the same 6. Do all this with no popup (Not sure of the exact order of the above.) Only way I can see a way out of this is: 1. Macro that creates a new file does HAS_PROFILE() call which returns false 2. Macro calls temp-profile-name = SAVE_TEMP_PROFILE(), which saves the current (modified) edit profile under some random name, which the function returns as a string. 3. Macro calls CREATE_NEW_PROFILE("PDQ", temp-profile-name) That's not hard at all, is it? R P.S. George, read your email Robert
Sorry, but you're not even close. If you don't understand what I was saying, why not simply ask instead of being dismissive?
All I asked for was the ability to CREATE a file of a new filetype WITHOUT SPFLite displaying a pop-up panel which requests information which is effectively already available. If it can copy a profile from the pop-up panel, it can copy the one that belongs to the file being edited. To include active profile changes was just icing on the cake and unnecessary in 99.99% of cases. I neither need nor want a bunch more Macro functions. I can circumvent the whole issue by creating the profile first so the filetype is known by the time the macro runs. The fact that it occurred in an EMACRO is completely irrelevant.
I started this thread because SPFLite craps out when this happens and the user replies to the 'macro looping' pop-up first.
I should have known you'd kick back aggressively. Unfortunately, that seems to be your standard response to anything 'not invented here'.
Your reaction and the tone in your post is disappointing.
|
|
|
|
Post by Stefan on Apr 30, 2022 5:14:20 GMT -5
Hi Robert - I see you're online. Hopefully you're back home from hospital and improving.
I've no wish to argue either and am happy to forget the whole thing.
It reminded me of a boss I had years ago.
We'd get into a dreadful tangle over some aspect behind closed doors, only to both come out realising that we were infact in agreement. We were just describing the same issue from different view points.
Thank you for your post. I'll grow a thicker skin and shall endeavour to be mindful of your health.
In the interest of other users, please feel free to remove my posts also.
|
|
