|
Post by George on Jan 26, 2021 11:52:10 GMT -5
Robert: SPFLite IS a GUI. Just a very simple one with a TAB Control, and each Tab containing a single Graphic Control.
There's nothing that says the FM Tab has to have the same set of controls as the other tabs in the control. Just as each of the tabs in the OPTIONS GUI are laid out differently.
Not to make light of what a change it would be, it's a total re-write and I'd have to figure out how to fully access and manipulate a LISTVIEW control (or whatever control would work best).
Still just dreaming here.
George
|
|
|
Post by George on Jan 26, 2021 13:32:06 GMT -5
Yeah, PB has what they call DDT (Dynamic Dialog Tools) which is a set of wrapper functions that basically use the standard SDK API under the covers. They really simplify doing all the GUI interfaces over writing them in native SDK. Although many PB programmers don't use DDT and write pure SDK, which to you would look a lot more like the C++ method of doing GUI stuff.
Like in SDK it would be: allocate a structure set Struct.Field1 = x set Struct.Field2 = y . . set Struct,Fieldn = something Call WinAPIFunction(structure, Handle) use Handle to control the GUI
Where with DDT it would be DDTFunction(x, y, ..., something) to Handle
Just imagine if the following, a stripped down code extract (which creates the main SPFLite window) had to be done in SDK mode. It would be pages long.
'----- Create a dummy invisible basic screen to get font sizes DIALOG NEW PIXELS, 0, "SPFLite", ENV.LastScreenX, ENV.LastScreenY, 200, 200, _ %WS_CAPTION OR %WS_THICKFRAME OR %WS_MINIMIZEBOX OR %WS_SYSMENU OR %WS_OVERLAPPEDWINDOW OR %WS_CLIPCHILDREN OR _ %WS_DISABLED, 0 TO ghWnd DIALOG SET ICON ghWnd, "A" ' Set TitleBaR Icon DIALOG SET COLOR ghWnd, %RGB_WHITE, %RGB_DIMGRAY ' Default color it DragAcceptFiles ghWnd, %TRUE ' Turn on Drag/Drop '----- Add the StatusBar CONTROL ADD STATUSBAR, ghWnd, %IDC_StatusBar, "", 0, 0, 0, 0, %CCS_BOTTOM, %WS_EX_WINDOWEDGE ' Add the Status Bar CONTROL HANDLE ghWnd, %IDC_StatusBar TO ghStatusBar ' Save its handle CONTROL SET FONT ghWnd, %IDC_StatusBar, gSBFont ' Set font CONTROL GET SIZE ghWnd, %IDC_StatusBar TO gSBWidth, gSBHeight ' Get the SB size gSBHeight += 4 ' Make it a bit bigger '----- Create a dummy Graphic window just to get Font sizes CONTROL ADD GRAPHIC, ghWnd, %IDC_SPFLiteWindow, "", 0, 0, 100, 100 GRAPHIC ATTACH ghWnd, %IDC_SPFLiteWindow ' Attach it FONT NEW ENV.FontName, ENV.FontPitch, ENV.FontStyle, 1, 1 TO gScrFont ' Get the basic font FONT NEW ENV.FontName, ENV.FontPitch, ENV.FontStyle + 4, 1, 1 TO gScrFontUnd ' Get the underline version of the basic font FONT NEW ENV.FontName, ENV.FontPitch, ENV.FontStyle + 8, 1, 1 TO gScrFontStrike' Get the strikethrough version of the basic font GRAPHIC SET FONT gScrFont ' Set the desired font GRAPHIC CELL SIZE TO gFontWidth, gFontHeight ' Get size of a character CONTROL KILL ghWnd, %IDC_SPFLiteWindow ' Kill dummy graphic area '----- Now calc our needed Graphic Window size x = (ENV.ScrWidth * gFontWidth) + %GLM + %GRM ' + the LM and RM pad values y = (ENV.ScrHeight * gFontHeight) ' Y '----- Now add a Tab control with no sizes yet CONTROL ADD TAB, ghWnd, %IDC_SPFLiteTAB, "", 0, 0, 0, 0, %TCS_OWNERDRAWFIXED CONTROL HANDLE ghWnd, %IDC_SPFLiteTab TO ghTab ' Get handle for Tab CONTROL SET FONT ghWnd, %IDC_SPFLiteTAB, gSBFont ' CONTROL SET COLOR ghWnd, %IDC_SPFLiteTAB, gStatFG, gStatBG1 ' Default color it '----- Set Rect to our needed Graphic size and then set the Tab to that size gTabRC.nTop = 0: gTabRC.nLeft = 0 ' Init Tab Rect gTabRC.nRight = x: gTabRC.nBottom = y ' TabCtrl_AdjustRect ghTab, 1, gTabRC ' Set Tab display to suit graphic TabCtrl_GetItemRect ghTab, 1, gTabHdrRC ' Get Tab title dimensions .nBottom = height CONTROL SET SIZE ghWnd, %IDC_SPFLiteTAB, gTabRC.nRight - gTabRC.nLeft, gTabRC.nBottom - gTabRC.nTop + gTabHdrRC.nBottom '----- Insert a page (will be used for the FM) TAB INSERT PAGE ghWnd, %IDC_SPFLiteTAB, TP.PgNumber, 0, $Empty, CALL DlgCallBack TO h TP.PgHandle = h ' Save the handle '----- Add our Graphic window to the new Page CONTROL ADD GRAPHIC, TP.PgHandle, TP.WindowID, "", 0, 0, x, y ' CONTROL HANDLE TP.PgHandle, TP.WindowID TO h ' Save handle to graphic window TP.gHandle = h ' GRAPHIC ATTACH TP.PgHandle, TP.WindowID ' Set as the default graphic area GRAPHIC CLEAR gTxtLoBG1 ' Clear the background TP.cCurrent = %False ' Set cursor state GRAPHIC SET FONT gScrFont ' Set the font TP.ScreenDim(ENV.ScrWidth) ' Redim the Screen shadow copy GRAPHIC GET DC TO hDC ' Get the DC for the graphic window gValidChars = FontGetValidChars(hDC) ' Build the valid chars list for this font '----- Now get the actual Tab size CONTROL GET SIZE ghWnd, %IDC_SPFLiteTAB TO nx, ny ' Now get the tab size DIALOG SET CLIENT ghWnd, nx, ny + gSBHeight ' Resize the whole dialog, allowing for the headers TAB SELECT ghWnd, %IDC_SPFLiteTAB, TP.PgNumber ' Select the FM Tab GRAPHIC REDRAW ' '----- Finally show the Dialog and let it run ENABLEWINDOW(ghWnd, %True) ' Remove disabled status DIALOG SHOW MODAL ghWnd CALL DlgCallback ' Fire up the main Dialog
|
|
|
Post by George on Jan 28, 2021 11:48:21 GMT -5
Remember way, way back we had a version (never got released) which had a "background" FM screen for every tab. And a toggle command that switched between the FM screen and the Edit screen. I can't remember the details, but while it sounded good, it was very unwieldy and confusing so we scrubbed it.
This would be a very significant change as right now all FM related data is basically stored globally. It would mean moving all that data into the local Tab storage which, while mechanical, is a big chunk of work. And it's not just a bunch of CHANGE ALL xxxx yyyy type thing.
Secondly, with two FM tabs, a lot of other stuff becomes more complicated. Do we always have 2 FMs? When a tab closes I'd assume we want to return to the originating FM tab. What if there wasn't one (i.e. Drag/Drop). Similarly RECALL would have to go back to the originating tab (if it exists).
All the cross-tab stuff done by FM (like Opening tabs, closing them etc.) has to be altered since most can now assume a return to Tab#1, which will no longer be the case.
All in all a very tough job.
George
|
|
|
Post by George on Jan 28, 2021 13:34:12 GMT -5
Maybe I could enhance (FMBack) and (FMFwd) to handle swapping between different FilePath entries. Right now it only supports swapping between modes, not recognizing FilePath's with different folders selected.
Then you could just display Folder 1 in FM, altering FM to display Folder 2, and then use (FMBack) and (FMFwd) to swap between the displays, no harder than flip-flopping between tabs.
Otherwise, you need to take a very deep breath and hold it, for multiple FM tabs to appear.
George
|
|
|
Post by George on Jan 28, 2021 16:10:52 GMT -5
Robert: Not sure what you're really looking for here. i.e. If Paths were altered to maintain last usage order (like Recent) wouldn't that do. (Not sure that it doesn't right now.)
I'm struggling to figure out just what it is you're really trying to accomplish. What does moving lines around to change the order do for you?
Mark me confused.
George
|
|
|
Post by George on Jan 28, 2021 16:19:14 GMT -5
Robert: Just a teaser of where I am currently.
|
|
|
Post by George on Jan 29, 2021 11:54:59 GMT -5
Well, just for comparison, I use Paths all the time, it's like a "Favorites" for FilePath.
e.g. Say I'm looking at my SPFLite development folder in FilePath, and I want to look at my TestData folder. One is on my D: drive, the other is on my E: drive. Neither is at the root level. Without Paths, I'd have to completely enter the full path on the FilePath screen to switch. With Paths, it's two clicks. And going back ditto - two clicks vs a lot of typing.
As to unwanted/unneeded folders in Path, how hard is a Forget line command? Maybe you browse around a lot more than I do in FM, I only have about 15 folders in there. But then for real 'browsing around' I use DOpus, a REAL FM.
So I'm still asking, if you have some kind of variation of Paths, with a variety of paths in there, and you can add/delete/move etc the entries around. Other than maintaining the list with all these lovely commands - What is it you can do that you can't do with the current Paths?
George
|
|
|
Post by George on Jan 29, 2021 11:57:27 GMT -5
Re: the mock up. It's not a mock up, it's alive and working, with left/right scrolling.
George
|
|
|
Post by George on Jan 29, 2021 15:23:07 GMT -5
OK, I understand what you're saying about how Paths doesn't suit you.
What I want to know is "What are you looking for as desirable?"
I.E. What would it Display? Where does it get it's display data? What selection operations would it provide?
I get that you don't like Paths. I don't get what it is you're after. I'm not trying to be awkward, but it's kinda hard to address how to improve on "I don't like the current ....." without some kind of target.
George
|
|
|
Post by George on Jan 31, 2021 15:39:46 GMT -5
Everyone:
If you have any ideas, suggestions, wishes etc. for the way FM works, ideas of enhancements etc.
Now is the time to voice them.
We're trying to improve it, but could really use some input to add to what our feeble minds can dream up.
Guessing what users would want or like, is not the way to go.
George
|
|
|
Post by Stefan on Feb 6, 2021 8:56:47 GMT -5
George, I'm right with you. I treat the PATHS list as a list of Favorite file directories/locations. It's broadly split into two sections - Stuff on my local drive and stuff on a shared drive on my NAS. As you say, two clicks and I'm away editing a different file. It's like a RECENT list but for File Directories, plus some staples I access a lot.
If you want to ADD the Date/time field data to the PATHS list so it can be sorted with recent entries at the top, I don't mind at all. But if you plan on fixing the sort order so that it ALWAYS shows the PATHS list in recent at the top' sequence, I would strongly disagree. I need the list to be sortable DIR+ NAME+ so that entries appear in a reliable place!
Robert,
"When I want to find some path, what I do is go to Windows File Explorer to find it. Then, I have a FE context extension I wrote, called PathClipper. That will put the path name of any path or file into the clipboard. I then go back to SPFLite and paste it in, either to edit it or bring up FM."
Even without anything fancy line PathClipper, you can already import any file to SPFLite simply by dragging its name from Windows Explorer to the SPFLite icon or into an open SPFLite window. To get the full directory path into the clipboard, you can simply click on the Drop-down arrow to the right of the path description field and press CTRL-C. Job done.
No reason to change what the SPFLite Paths List does today.
I don't really see the need for FM to become a fully fledged File Manager, including file types which the rest of SPFLite does/can not easily support. For example, FM's display of MP3 files and their tag values is pretty, but Windows Explorer already does this.
The question is, is that display useful/productive given SPFLite can neither display meaningful data for MP3s nor offer a 'edit' facility for the tag values? (Yes I know this could be achieved via XFORM but XFORM would also be invoked if I just dragged an MP3 file from Windows Explorer to the SPFLite window/icon.)
|
|
|
Post by Stefan on Feb 6, 2021 9:42:24 GMT -5
George, One suggestion I have (apologies if this has already been discarded), is that SPFLite adds to the FM List any other entries it finds in it's FILELIST folder. So if a user adds an XYZ.FLIST entry to that folder, 'XYZ' appears in FM next to the exiting FLIST entries. Similarly, if a user removes one of the 'stock' FLIST files, it is removed from the FM display. I appreciate there's no pressing need for this, given that we can already select an 'added' XYZ.FLIST via FM's FLIST list, albeit via an extra mouse click.
It would just be 'neater'.
|
|
|
Post by Stefan on Feb 6, 2021 10:59:10 GMT -5
Let me try and clarify... Usually, the FILELIST folder in the SPFLite "data directory" contains Favorite Files.FLIST Found Files.FLIST Open Files.FLIST Recent Files.FLIST Recent Paths.FLIST I was suggesting that if a user adds an "XYZ Files.FLIST" to the FILELIST folder, the first word of the name (XYZ in this instance) is added to the FM line next to FOUND, OPEN, FAVORITES, etc. To cater for your use case (user added an FLIST but doesn't want it on the FM panel), the name could start with a suitable character eg. XYZ Files.FLIST becomes -XYZ Files.FLIST.
None of this is related to Recent Paths.FLIST in any shape or form. It's just another FLIST
|
|
|
Post by George on Feb 6, 2021 11:43:51 GMT -5
Stefan: Robert:
The Recent-Files and Recent-Paths display will show the last date used and (mainly for Files) the mode of access (OPEN, CREATE, REPLACE, SAVEAS etc.) You can sort on these columns just as any other columns, and just as before, the sort chosen is remembered for the next time the display is chosen.
I too don't quite get Stefan's FileList comments. Filelist already selects all .FLIST files in the folder, so I'm not clear what other files are referred to.
As to Extended properties, it was an interesting challenge (especially getting column sorting to work), and obviously for most of us, not really too useful, we'll just ignore it. Besides when Extended Attributes are chosen, and there are a large # of files selected, the extra processing delay can be noticeable.
A couple new columns are available CCRDATE is added in addition to DATE (Which is now renamed to LWDate). And ATTR which displays the file attribute (System, Hidden, RO, Archive, etc)
The FilePath display can now be asked to recurse into folders. (i.e. do the whole folder tree.)
When more columns are chosen and won't fit on the screen, the normal LEFT and RIGHT keys will scroll columns left and right. The first column (FNAME) is frozen, columns 2 to n are scrollable. Scrolling is by column, not by character.
99% of the above is now working.
George
|
|
|
Post by Stefan on Feb 6, 2021 12:34:42 GMT -5
George, It isn't about what Filelist selects. If I click on FLISTS and then on the user-added flist, it get there. I said that in my post.
Why shouldn't the user-added "XYZ Files.FLIST" appear as an option in the FM list directly? (e.g. New FilePath Recent Found Opened Favorites XYZ Flists Paths Configs" Your choice where in the list it appears. If a user adds more FLISTS that there is room for in the list - just display the first 'n' you find.
No big deal if you don't want to change it. Possibly a lot of coding to save the user a click via the existing FLISTS list.
The other changes look interesting. Thank you.
|
|