LB Booster
General >> General Board >> little problem with file selection dialog
http://lbb.conforums.com/index.cgi?board=general&action=display&num=1458739763

little problem with file selection dialog
Post by pierscintilla on Mar 23rd, 2016, 1:29pm

Hello.
Is with great pleasure that I learned the release of LBB 3.0.4.
On this occasion I would like to inform that i have compiled a program LB 4.04 with LBB 3.0.1 and also with LBB 3.03.
The program uses the file selection dialog and then performs various calculations on the data from the selected file. The surprise is that, at the end of calculations, the sw compiled with LBB 3.0.1, if i want to reopen the selection window for process a new file, the starting folder is the last used instead for the sw compiled with 3.0.3 the starting folder is where the program is installed and this is very uncomfortable..
Any idea?
Re: little problem with file selection dialog
Post by Richard Russell on Mar 23rd, 2016, 1:59pm

on Mar 23rd, 2016, 1:29pm, pierscintilla wrote:
Any idea?

The rules governing in which directory the GetOpenFileName API initially opens are complicated and depend on the version of Windows. You can find a description of those rules at MSDN here. Look specifically under lpstrInitialDir on that page.

Many people (including me) think that the change Microsoft made in Windows 7 and later was unfortunate. If you scroll down to the Community Additions you will find comments such as "Ignoring lpstrInitialDir is insane". I am not a 'Microsoft hater' but in this particular respect I think the criticisms are justified.

So I can only repeat my assurance that the difference you think you have seen between LBB 3.01 and LBB 3.04 is in fact nothing at all to do with LBB. The two compiled executables are behaving differently because of the way Windows works. Feel free to complain to Microsoft, but please don't complain to me!

Edit: I should perhaps add that if you don't like the way Windows behaves in respect of selecting the initial directory you can of course always specify it yourself:

Code:
    FILEDIALOG "My Title", "C:\My\Initial\Directory\*.ext", returnvar$ 

Richard.

Re: little problem with file selection dialog
Post by pierscintilla on Mar 24th, 2016, 08:17am

Dear Richard, I did not mean "complain" with you (which indeed thank you very much for the work you continue to make) and I do not doubt that what you say is true but the problem that I observe is really very strange.

I tried to compile the same program with version 3.01 and version 3.03 at a few seconds away and to launch the two executables obtained at a few seconds of each other on the same machine with the same S.O. (Win7 Pro x64 SP1) and i confirm that the results are what I said in my first post. For me it is difficult to understand even if, as I said, I do not doubt your explanation.
Re: little problem with file selection dialog
Post by Richard Russell on Mar 24th, 2016, 11:11am

on Mar 24th, 2016, 08:17am, pierscintilla wrote:
I tried to compile the same program with version 3.01 and version 3.03

Do you mean version 3.03? The current version (released last week) is 3.04.

Quote:
For me it is difficult to understand.

Presumably when you are compiling your two executables you are giving them different filenames, or saving them in different folders. It will be this (not the version of LBB) which is resulting in the different behaviour. Windows keeps a separate record for each individual executable of what initial directory it will select when a GetOpenFileName dialog opens (according to the rules I linked to previously).

If you are particularly concerned that your FILEDIALOG opens in a specific place, why do you not force that in your own code rather than relying on Windows to make the choice?

Richard.
Re: little problem with file selection dialog
Post by pierscintilla on Mar 24th, 2016, 4:37pm

- Actually this is not a big problem for me, is just a uncomfortable. I reported only a strange behavior.
- I can not handle this "problem" with the code because the folders where the data resides may be many and varied.
- My observation is about the version 3.0.3 but also the 3.0.4 that behave it exactly in the same way but not in the same way of the version 3.0.1.

Regarding your assumptions I'm sorry but is not the explanation (I attach the sequence of my actions):
1) I launch LBB 3.0.3 (or 3.0.4 is the same thing)
2) I load the LB program from its folder
3) I compile the program and then saving it, without changing its name, in its folder
4) I launch the executable obtained (now does not "remember" the last used folder)
5) After this I erase this executable
6) I launch LBB 3.0.1
7) load again exactly the same LB program (with the same name like before) exactly by the same folder as before
8) I compile again the program and saving it, without changing the name, in the LB program folder as before
9) Now I launch the executable obtained that now "remember" the last used folder !!

I tried many times on different machines with the same O.S. with the same results.

Probably this will not help you but the file size compiled with LBB 3.0.1 is 127728 bytes, the one compiled with LBB 3.0.3 is 128000 bytes and the one compiled with LBB 3.0.4 is 128224 bytes.

I do not want you to lose valuable time. Considers this as a information..
Re: little problem with file selection dialog
Post by Richard Russell on Mar 24th, 2016, 6:11pm

on Mar 24th, 2016, 4:37pm, pierscintilla wrote:
Regarding your assumptions I'm sorry but is not the explanation

I have double-checked that there was no change to the code of FILEDIALOG between v3.01 and v3.04. However, there was a change between v3.00 and v3.01, which might explain your observation.

I do not understand how this is possible, but I can only assume that the version you have which is reporting as v3.01 is actually (at least in part) v3.00. LBB consists of two modules: the IDE and the LBLIB library. Perhaps by some mysterious mechanism you have the v3.01 IDE but the v3.00 library!

If this is the explanation it leaves me with something of a dilemma. v3.02 was released on 8th September 2015 and v3.03 on 19th September (more than six months ago); why is it that you have not commented on this issue until now?

How do you want me to proceed? Do you want me to restore FILEDIALOG to how it was in version 3.00? How do LB 4.04 and LB 4.5.0 behave?

Richard.

Re: little problem with file selection dialog
Post by pierscintilla on Mar 24th, 2016, 7:58pm

Actually I program occasionally enough and for some time i did not use the filedialog.
I don't know all the differences between the filedialog of LBB 3.0.0 and the next but, for the aspect in discussion, the version 3.0.0 is better for me.

On LB 4.04 the filedialog not remember the last used position rolleyes
Re: little problem with file selection dialog
Post by Richard Russell on Mar 24th, 2016, 9:26pm

on Mar 24th, 2016, 7:58pm, pierscintilla wrote:
On LB 4.04 the filedialog not remember the last used position ::)

That's what I suspected - in fact I'm pretty sure I changed the LBB behaviour in order to improve compatibility with LB 4.

The difficulty I face is that whatever I do I will probably upset somebody. The way it works now programs will run as they would in LB4. If I restore the v3.00 behaviour FILEDIALOG will open where Windows decides is best (which depends on a number of factors) and compatibility may suffer. But it would mean that - in some circumstances at least - the 'last selected' directory will be remembered which can be a useful feature.

It's perhaps worth pointing out that if I do revert to the earlier behaviour it would be possible to force FILEDIALOG to open in the 'current directory' (DefaultDir$) by prefixing the template string with ".\":

Code:
    FILEDIALOG "Test", ".\*.bas", returnVar$ 

So can I ask for people's opinion? I will assume that pierscintilla's vote is for the v3.00 behaviour!

Richard.

Re: little problem with file selection dialog
Post by michael on Mar 24th, 2016, 9:45pm

Directory history and remembering where something is is a very important feature. Would be nice to have a directory history feature built in both your IDE platforms also since that would definitely put them on another level altogether.
Once a directory is changed LBB and BBC look for the required files/libraries in the current directory you have selected.
Having a directory history would allow a search history to be executed and things would be soo much easier. And I suspect such a feature could be made by making the IDE record the saves and loads directory paths in a file directory/path history folder( which would also need to be remembered, but that could be updated and carried in any directory you move to..as well as in the core directory..)

SO the file directory path file would be updated in the old location, and as well as in any directory that you save or load from... (safeguards would need to be made for read only sources)

Re: little problem with file selection dialog
Post by Richard Russell on Mar 24th, 2016, 10:16pm

on Mar 24th, 2016, 9:45pm, michael wrote:
Would be nice to have a directory history feature built in both your IDE platforms also since that would definitely put them on another level altogether.

Windows 10 already provides a similar functionality in its 'Quick access' feature. Because LBB (both the IDE and the interpreter) utilises the standard GetOpenFileName dialog this functionality is made available without any extra effort.

Anyway I don't want to divert attention from the current issue which is specifically related to the FILEDIALOG statement in LBB.

Richard.

Re: little problem with file selection dialog
Post by RobM on Mar 25th, 2016, 12:25am

on Mar 24th, 2016, 9:26pm, Richard Russell wrote:
So can I ask for people's opinion? I will assume that pierscintilla's vote is for the v3.00 behaviour!

Richard.


I always specify the directory so any change probably wouldn't have an effect on my program. I also save the user's chosen directory in a settings file and use that if it is different than the default.
Re: little problem with file selection dialog
Post by joker on Mar 25th, 2016, 12:35am

I don't see this as a problem except in a development situation.

In my app, I'm always keeping track of the file locations.

I say use your current strategy of trying to keep up with the LB screw ups. wink
Re: little problem with file selection dialog
Post by pierscintilla on Mar 25th, 2016, 7:34pm

Obviously I vote for version 3.0.0 and this is because:

1) being windows that decide which is the starting folder (usually the last used folder), the user will have behavior very "familiar" because it will be the behavior of "his Windows"

2) it is certainly possible to adopt the RobM solution (which however may require a first "adjustment" in case the starting folder was not the desired one) but this solution is far more complicated than a simple ".\" that is also an extremely intuitive solution!!

3) are not at all agree with the statement of pnlawrence according to which the problem would arise only in development and that proposes the same mechanism RobM

4) even in the case where the desired starting folder must be always (or almost always be) the DefaultDir$ and for some reason, occasionally, the user select a different folder, even in the case of version 3.0.0 it would be enough return only once at DefaultDir (also without placing this in the code) that this folder remain selected for future selections

5) is not the first time that the LBB behavior differs in part from that of LB to get better results and LBB (!!) has a nice help menu to resolve problems.

Also on Allincon comments I say that the "full path" is almost never available before the selection by the user (if that is not the case, I think that in practice would serve little the filedialog) and the "full path" is also the ".\"...

But, of course, I accept the decision of the people (naturally hoping that increase those who think like me about it) grin
Re: little problem with file selection dialog
Post by Alincon on Mar 25th, 2016, 7:35pm

I would prefer not going backwards on the file dialog question when it seems so simple to just use the full path, as you mentioned above

r.m.
Re: little problem with file selection dialog
Post by Richard Russell on Mar 26th, 2016, 11:19am

on Mar 25th, 2016, 7:34pm, pierscintilla wrote:
the user will have behavior very "familiar" because it will be the behavior of "his Windows"

I'm not sure that's true. Since the behaviour depends on what the application specifies in the lpstrInitialDir and lpstrFile members there is no 'standard' or 'universal' behaviour for the user to have become familiar with. What you are asking for is what happens when lpstrInitialDir is NULL and lpstrFile contains no path, but that's just as much a 'special case' as what LBB 3.04 does now!

Quote:
this solution is far more complicated than a simple ".\" that is also an extremely intuitive solution!!

I agree that RobM's solution is a lot of work, especially if the program doesn't otherwise need to store any custom information from one run to the next.

Quote:
it would be enough return only once at DefaultDir (also without placing this in the code) that this folder remain selected for future selections

That is, I think, the best argument for your case. It's easy to make the v3.00 behaviour 'mimic' the LB4 behaviour (either in code, by explicitly prefixing a ".\" path, or through the user just once selecting that folder) but it's difficult to make v3.04 mimic the v3.00 behaviour (relies on RobM's technique of storing the user's selection).

Quote:
is not the first time that the LBB behavior differs in part from that of LB to get better results

Indeed. However where possible I try to avoid 'enhanced' LBB behaviour compromising compatibility with LB 4, which in this case it does (although in a relatively minor way).

Quote:
But, of course, I accept the decision of the people

The feedback so far has been insufficient to say that there has been a "decision". I will wait a while and hope that more people express their views.

Richard.

Re: little problem with file selection dialog
Post by RobM on Mar 26th, 2016, 3:13pm

I wouldn't say the way I do it is a lot of work but it is necessary for my program. It only opens one file type but I create and save 4 different file types which the user may want to store in different locations.

This is what I use for setting up the file dialog and how the info is saved. Not too many lines ;)

Code:
      gosub [OpenStandards]
      gettrim #stan, SettingsNum
      close #stan
      if lastcsvfolder$<>"" then
        StartPath$ = lastcsvfolder$;"*.csv"
        else
        StartPath$ = GetSpecialfolder$(5);"*.csv"
      end if
      filedialog "Select CSV file name and save location", StartPath$, CSVfile$
      if CSVfile$<>"" then
        l=len(CSVfile$)
        temp$=CSVfile$
        while right$(temp$,1)<>"\"
          l=l-1
          temp$=left$(temp$,l)
        wend
        gosub [OpenStandards]
        lastcsvfolder$=temp$
        put #stan, SettingsNum
        close #stan
      end if
 

Re: little problem with file selection dialog
Post by pierscintilla on Mar 27th, 2016, 09:06am

Happy Easter to everybody and I wish you to enjoy a little rest at least for today!

As for the "referendum" on filedialog, I believe that the answers may be more "weighted" if Richard could provide a short list of the behavioral differences between the two versions in discussion possibly with a short comment on the pros and the cons for each difference and possible ways of passing each against but I realize that it is much to ask....

For RooM: probably is not a "lot of work" in absolut but always much worse than a simple ". \" (especially if you do not need that).
I prefer to spend my time on more important aspects of my sw and I remain faithful to the famous "KISS" principle that we all know (Keep It Simple etc ..) cheesy

Good day
Pier
Re: little problem with file selection dialog
Post by Richard Russell on Mar 27th, 2016, 1:59pm

on Mar 27th, 2016, 09:06am, pierscintilla wrote:
if Richard could provide a short list of the behavioral differences between the two versions in discussion possibly with a short comment on the pros and the cons for each difference and possible ways of passing each against but I realize that it is much to ask....

I don't think there's much more to say than what has been said already:

Option 1 (status quo):

The second parameter of FILEDIALOG ('template') is handled in the standard way that Windows normally treats filenames:As far as I am aware this is identical to how LB 4.04 and 4.5.0 behave.

Option 2 (change):

If the second parameter of FILEDIALOG ('template') contains an absolute or relative path the behaviour is the same as Option 1 above, but if it contains no path the behaviour is different:In most cases, therefore, the application will 'remember' the directory which was most recently selected.

If I don't make a change, an equivalent behaviour to Option 2 above can be emulated by saving the selected path to the registry or file, and using that as the initial directory next time (as RobM described).

If I do make a change, an equivalent behaviour to Option 1 above can be emulated by prefixing the template string with ".\".

Richard.

Re: little problem with file selection dialog
Post by Richard Russell on Mar 30th, 2016, 11:42am

on Mar 27th, 2016, 1:59pm, Richard Russell wrote:
Option 1 (status quo):
Option 2 (change):

I described the options in as much detail as I could, but there's been no response since. Let me turn the question around and put pierscintilla's case more directly: would anybody actually have any objection to me making the change he has asked for? Would anybody's program(s) be adversely affected by that change?

Richard.

Re: little problem with file selection dialog
Post by Jack Kelly on Mar 30th, 2016, 4:16pm

FileDialog is ok for me either way. Why don't you do what's best for Rob in Cabinet Planner.
Re: little problem with file selection dialog
Post by Richard Russell on Mar 30th, 2016, 4:25pm

on Mar 30th, 2016, 4:16pm, Jack Kelly wrote:
FileDialog is ok for me either way. Why don't you do what's best for Rob in Cabinet Planner.

Rob said it would make no difference to CP, because he always explicitly sets the initial directory.

Richard.

Re: little problem with file selection dialog
Post by RobM on Mar 30th, 2016, 4:39pm

I think option 2, having the filedialog remember the last directory if none is specified, would be best. That is normal for most programs.
Re: little problem with file selection dialog
Post by pierscintilla on Mar 30th, 2016, 5:00pm

Thank once again Richard for the tireless commitment that he shows!!
Re: little problem with file selection dialog
Post by joker on Mar 31st, 2016, 09:26am

Option 2 is actually how I like to operate anyway, by default. I would have no objections.

And ... change is good! Keeps 'em guessing! cheesy
Re: little problem with file selection dialog
Post by Richard Russell on Apr 19th, 2016, 11:32am

Just to say that I've not forgotten about this, but it's not high on my list of priorities. It was, after all, more than six months before the change in the behavior of the FILEDIALOG in v3.01, to improve the compatibility with LB 4, was even commented upon!

As the preference, on balance, seems to be to reverse that change I will tentatively aim to do so around June, which is the next date on which I would normally be considering an update (always assuming that by then I've not once again 'abandoned' LBB, which on past experience is entirely possible!).

Richard.

Re: little problem with file selection dialog
Post by pierscintilla on Apr 19th, 2016, 4:58pm

Thanks for your answer and we hope that does not abandon LBB !!

Pier