|
|
Post by George on Nov 25, 2022 11:26:11 GMT -5
Robert: Many of the boxes are multi-use ones where different messages can appear at different times, all with differing lengths. For some, this gets ridiculous when you can have line counts over 1,000,000 and line lengths that go on forever. e.g with my LARGE.TXT file, if I mark a small area, one box ends up as: @ 1 10 # .1542010 .1542014 - now imagine if the columns had been 9500 to 10125
For this change, I went through all the messages for each box and assigned a longest message length. I suspect this is the result. I don't have any other ideas how to manage this. If you have some bright idea, speak up.
The boxes can't be dynamic, having them jump around resizing for every message change would drive anyone nuts.
The only solution right now is to drop some of the boxes from the display.
George
|
|
|
|
Post by George on Nov 25, 2022 13:50:51 GMT -5
OK, dynamic clicking to change sizes is a non-starter. We already have a couple of clickable boxes, I ain't touching that.
Adding (nn) to the SB setup list is certainly do-able, but a royal PITA. a) Startup has to parse it out and set it up, b) the options dialog callback has to parse and validate it before saving to the CFG, and then do the setup stuff, and c) some one-time code has to be added to Startup to migrate the existing CFG entries. Meaning no going back a release.
A lot of effort to avoid dropping 1 or 2 boxes from the display.
|
|
|
|
Post by George on Nov 25, 2022 16:01:30 GMT -5
You make it all sound so simple. OK, we have clickable boxes now, so what does that mean. We no longer support them because now the clicks are taken to be requests for re-sizing? I suppose you'd want a pop-up box if it's one of the existing boxes and ask the user "Do you want to resize? Or do you want to ... whatever the old function was?
I'm not even sure if Windows tells me which click it was (Left vs Right). You always seem to forget this is Windows, I don't get mouse click addresses and then figure out where those clicks were made. Windows doesn't work that way in the SB. The SB is Windows controlled.
As to parsing all this - it's not the parsing, Sheesh! anyone can do that. It's the NEED to do it to solve this problem. It's another one of those - add code here, add code there, add code somewhere else etc. And then document the whole mess.
All 'cus you don't want to drop 1-2 boxes from the SB.
Years? From what I can check in old archived stuff, I think it was probably 2008 - 2010, but it might have been earlier.
|
|
|
|
Post by George on Nov 26, 2022 12:36:48 GMT -5
Simple answer - no it's not better, it's different, and worse.
The KB routine is already branched and forked all over the place to handle various modes and combinations with cursor locations. Insert / NonInsert / LineNo area / Text area / Scroll Area / Command line / PT Mode / FM Mode etc.
Now you want a (StatusBar) mode.
Assuming I get the KB part working, I then have to alter DoStatusBar, StatusBarDrawItem, StatusBarSetup so they can handle the drawing while in (StatusBar) mode.
And since, of course, these values need to be saved, I get to modify ENV to save and reload the values, add some code to update the current fixed values. Then I can modify the Options GUI callback routine to validate the newly saved values, update the current tables, etc. Don't forget to update CFGMaint as well to ensure it will handle these new values and can export/import them correctly.
As you said "This is better, right?"
So, so wrong.
But don't despair, I will look closer at adding a user specified length to the SB field list.
|
|
|
|
Post by George on Nov 26, 2022 15:26:48 GMT -5
OK, next Beta will allow you to add a (nn) value to SB layout names to specify the nominal length in characters.
Surprisingly difficult as it showed up some quirks in very old routines that haven't been looked at in years.
George
|
|
|
|
Post by George on Nov 27, 2022 10:45:05 GMT -5
Robert: the (nn) is optional, and will be appended to the field name - e.g. MODE(10). The value is in character widths.
Right now, the SB Layout only shows the value if it's added, so no, there's no old default value shown. I tried to avoid yet another chunk of one time migration code needed to modify the existing string.
Obviously that doesn't satisfy you, so I'll go cram in more code to keep you happy.
As I've said many times, you love make work changes.
|
|
|
|
Post by George on Nov 27, 2022 12:03:49 GMT -5
It's easier to add a one time routine rather than clutter up the normal stuff. Besides, I can simply yank the one-time code in a couple more releases.
The big problem is the OPTIONS dialog. Every time DONE is pressed, EVERY field on EVERY Options Tab has to be verified before ANY of the data can be stored away. So there's this long stretch of code doing the verify, then followed by a very similar long stretch of code massaging the data into it's internal storage form and saving it away.
Some data is simple, a Y/N type flag doesn't even need validating, the dialog can only return True or False. Others, like the SB Layout need field names validated, duplicates scanned for, valid values in (..) etc. All done almost twice.
To prepopulate with default values means going into the Dialog Build routine and massaging the field before it gets displayed, and that's in addition to the previous validation and save part, which HAS to be done. Dialog build is now over 500+ lines of dense code, it doesn't need any more junk code added to it.
George
|
|
|
|
Post by George on Nov 27, 2022 15:46:42 GMT -5
No, not a logic change, but a simple string of "MODE,LINNO,LINES ..." etc
Becomes "MODE(" + format$(gSBTable(n).SBMaxTxt) + "),LINNO(" + format$(gSBTable(n).SBMaxTxt) + "),LINES( ... etc for the 15 or so valid entries.
Thanks for suggesting such a soul destroying coding exercise.
Sure, put it in a loop, but then it becomes multiple loops as I experiment with 'how much fits on line 1', how much fits on line 2, etc.
I think sometime, you should code a reasonably complex dialog and see what it really takes to do all this. So when you make a suggestion you have some idea what you're asking for. This is not VB, with a Dialog designer built in.
George
|
|
|
|
Post by George on Nov 28, 2022 9:44:49 GMT -5
No, a little program / #INCLUDE file is stupendous overkill, especially since the table is only created and built in mainline SPFLite.
I'll just have to crank out a couple of For/Next loops and grind it out.
You're right, these are pain-in-the-neck chores that maybe 1% of users will ever notice.
|
|
|
|
Post by George on Nov 28, 2022 13:58:03 GMT -5
Well, this release has one of the largest collections of bug fixes and enhancements we're had, what's another one. And I've just fixed another bug with HEX and MEdit not getting along.
Besides, as developers we both get priority (assuming we don't have swords raised)
George
|
|
|
|
Post by Stefan on Nov 28, 2022 16:51:32 GMT -5
George, Just a comment... I exported the CFG to make the a bulk change to all my file profiles (basically IMPORTTABS=0) Made the change, and saved the EXPORT file. When I IMPORTed the modified EXPORT file, using the version of CFGMAINT currently on the 'latest beta' page with SPFLite v2.7.22332, I had this message: CFGMaint - Table: ODEFAULT, Entry: SBLAYOUT=MODE(15),LINNO(20),LINES(15),COLS(23),BNDS(20),INSOVR(4),CASE(4),CHANGE(3),STATE(3),MISC(25),SELECT(30),CAPS(9),SOURCE(8),EOL(7), IS invalid, It will be corrected TO: MODE,LINNO,LINES,COLS,BNDS,INSOVR,CASE,CHANGE,STATE,MISC,SELECT,CAPS,SOURCE,EOL
Fair enough I thought, George hasn't updated CFGMAINT.EXE following the Status Bar mods he's made.
Bizarrely though, on the OPTIONS when I enter OPTIONS - STATUS, all looks perfectly as expected. So the corrections were NOT applied afterall.
|
|
|
|
Post by George on Nov 29, 2022 9:32:00 GMT -5
No, if there are no (..) lengths in SBLayout, a one time conversion is done adding the default lengths.
But yes, CFGMaint is still not done yet. Have to do that today.
George
|
|
