R60
Freshman Member
Posts: 32
|
Post by R60 on Mar 10, 2015 5:56:46 GMT -5
George: Now I can explain further.
It takes more than 1 hour on 3 PC's with 3 different Windows operating systems and this is the result: It's not a problem with dots in the directory name, it's more a general problem. I start testing the SPFLite without reading all the documentation yet. And try the 'File Manager' as a simple 'ISPF 3.4' replacement to navigate through my directories to get to the files for editing. I don't know why, but I use the 'File Patterns' "*.*" instead of "*". With pattern "*.*" files with no extention (like .txt or .whatever) are not displayed by File Manager. If pattern "*" is used, everything looks fine. And this was my problem, because the directories acts as a z/OS PDS/E data sets holding files with a max. length of 8 chars and without any file extention (simulating the members within a partitioned organized data set).
Back to SPFLite: In the documentation, section 'Working with the File Manager' under 'File Patterns', the text is: ...To display all files in a directory, specify * or *.* as usual...
Now it's your part. Code or Docu change ?
The next days I continue my testing, reading more of the SPFLite documentations and try to became more familiar with it. Let me know, what you find out. Please confirm my findings (if so) and what's your decision.
|
|
|
Post by George on Mar 10, 2015 10:51:37 GMT -5
R60: My first reaction without looking at the code is that * and *.* are NOT the same. An * matches anything, an *.* matches anything - period - anything. So the next question is, does 'anything' match 'nothing'. And I think it should.
But that still means *.* is saying the period must be present.
So, I'll go check the code to see if * matches nothing (or null) and whether the period MUST be present. I'll edit this with the results of my search.
George
OK, * and *.* are not the same. Other than * and ? characters in the mask, all other characters MUST appear, the period is not considered special. And * does match a null string as far as I can see reading the code, I didn't try any actual tests.
George
|
|
R60
Freshman Member
Posts: 32
|
Post by R60 on Mar 10, 2015 11:12:59 GMT -5
George: Alright. Btw: Warm-up started. There are 3 more threads (Problems and Bugs, Suggestions, How can I ...). I don't like to keep you busy, but that's what I found (only the highlights until now).
|
|
|
Post by George on Mar 14, 2015 15:22:17 GMT -5
R60: I have an updated version if you'd like to be a Beta tester. It corrects the rename in the root folder of a drive, as well, it has improved handling of list and cursor positions when traversing folder structures up and down. If you'd like to try it, download www.spflite.com/Files/SPFLite815072.ex_ - rename to SPFLite.EXE and copy into the normal install folder. Please note, that once you have used this version, if you back off to a previous version, your existing FLIST files will not function. The change involves moving from a comma delimiter in those files to a | (vertical bar). If you go back, the FLISTS would need manual editing to change all | back to commas. If you try it, please post your comments. George
|
|
R60
Freshman Member
Posts: 32
|
Post by R60 on Mar 21, 2015 16:57:21 GMT -5
George: Thx for the very fast update to the code and this beta version (8.1.5073).
Here are the results of my test:
1. No more problems with a directory/folder with a ',' (comma) in the name. I think - problem solved !
2. Rename of a file in the root folder of a drive: Also solved ! May be it would be good for other user's if you also establish a note for the solution in the thread "Strange behavior in File Manager for ‘rename’ of a file".
3. Now some more words to the 'Suggestions' thread "Keep FM screen position when returning from DIR selection", which is one of my big issues. (like 2. - it would be good for other's to establish a note in this thread, that there is/could be a solution by this beta version).
The new beta version: For long directory/folder lists the position is kept after return from the selection - the cursor is in front of the last/current selected directory - and the color of the name is displayed in green. That's fine, it looks like the same behavior when selecting files. So far. so good - and yes, it looks like the solution for my request. But I'm so sorry, here are the ifs and buts: I hope the following behavior can be changed and depends on the quick change to the program.
- If you return from a DIR selection (as described above) and the cursor is in front of the last selected DIR and you type "s" again, the DIR will be selected immediately without pressing ENTER (unexpected behavior). If you press ENTER after return from a selection and then type "s" for a new selection, the ENTER is required (as expected).
- In this version (8.1.5073) when returning from a file selection the cursor is no longer in front of the selected file and the name is also not displayed in green. Here i expect the same behavior as in the previous 8.1.5002 version. May be,that this also depends on your 'quick' change and you can correct it, because this is unexpected for me.
Sorry for this, but I know '...never change a running programm...' and '...if it works, don't fix it...'.
|
|
|
Post by George on Mar 22, 2015 11:04:13 GMT -5
R60: Thanks for doing the testing. I'll have a look at the two things you mentioned (lack of Enter needed, and positioning on a select/return) The 2nd is probably due to the change I made for the other positioning, I think a tweak will fix it. The Enter thing is odd, I'll have to dig a bit.
George
|
|
|
Post by George on Mar 22, 2015 13:25:13 GMT -5
R60: OK, I've explored the positioning after returning from an Edit of a file, and this one I'm afraid is not solvable. Because of the data isolation between tabs, the edit tabs have no knowledge of what has or has not been going on in the FM tab. (and visa versa)
You could, for example, have used a FilePath display to select AAA.TXT for editing, swapped back to FM, chosen Favorites, and selected BBB.TXT for editing, then back to FM and gone back to FilePath, gone up/down some directories and selected CCC.TXT for editing.
Now you go back to AAA.TXT and END the edit. There's no way you'd expect (or want) the ending of that Edit to rip out your current position in FM and try and put it back to where it was when AAA.TXT was originally selected.
An additional problem is that, so that the FM data properly reflects the current file system state, whenever a switch is made back to FM from an Edit tab, the FM data is refreshed from Disk. e.g. maybe you did a RENAME command in the Edit tab, you'd expect FM to display the newly chosen name and would be complaining if it didn't. Because of this refresh, no FM positioning can be retained. Well, it could, but it would mean matching the previous state against the newly loaded state and attempting to reposition on a 'best efforts' basis. And frankly, I'll never even consider trying that.
So I'm afraid that this positioning oddity is something you'll just have to put up with. I've tried various methods over the years to 'solve' this. At best some of them 'sort of' worked, but not with 100% consistency; they created more questions than they answered. At this point I have no plans to make another attempt.
I'll continue working on the Enter key problem.
George
P.S. The extraneous Enter bug has been corrected.
|
|
R60
Freshman Member
Posts: 32
|
Post by R60 on Mar 22, 2015 18:21:30 GMT -5
George: Alright... But what I like to tell you is: The current version 8.1.5002 keep the position of the edited file if you use FM and edit only one file and return from this edit session. The beta version of SPFLite does this for directories/folders (my wish) but no longer for files.
Please give me some more info, because in the moment I have to deal between keeping file position (current version) or keeping directory position (beta version).
|
|
|
Post by George on Mar 23, 2015 10:53:44 GMT -5
R60: What more info would you like? I think I've explained it pretty completely. Fixing the directory position killed the file position. Yes, in prior versions the file re-positioning would seem to work, but it only did so if you simply edit a single file at a time, once you get to multiple edit tabs, it falls apart. For the reasons I described, a general solution simply does not exist. I know what you'd like, I know why you'd like it, but right now I have no idea how to provide it.
George
|
|