Author |
Topic: little problem with file selection dialog (Read 2170 times) |
|
pierscintilla
New Member
member is offline
Gender: 
Posts: 30
|
 |
little problem with file selection dialog
« Thread started 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?
|
|
 Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: little problem with file selection dialog
« Reply #1 on: Mar 23rd, 2016, 1:59pm » |
|
on Mar 23rd, 2016, 1:29pm, pierscintilla wrote:
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.
|
|
|
|
pierscintilla
New Member
member is offline
Gender:
Posts: 30
|
|
Re: little problem with file selection dialog
« Reply #2 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.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: little problem with file selection dialog
« Reply #3 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.
|
|
Logged
|
|
|
|
pierscintilla
New Member
member is offline
Gender:
Posts: 30
|
|
Re: little problem with file selection dialog
« Reply #4 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..
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: little problem with file selection dialog
« Reply #5 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.
|
|
|
|
pierscintilla
New Member
member is offline
Gender:
Posts: 30
|
|
Re: little problem with file selection dialog
« Reply #6 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 
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: little problem with file selection dialog
« Reply #7 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.
|
|
|
|
michael
New Member
member is offline
Posts: 28
|
|
Re: little problem with file selection dialog
« Reply #8 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)
|
|
Logged
|
I make program generators and some utilities. Its my hobby
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: little problem with file selection dialog
« Reply #9 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.
|
|
Logged
|
|
|
|
RobM
Junior Member
member is online
Posts: 91
|
|
Re: little problem with file selection dialog
« Reply #10 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.
|
|
Logged
|
|
|
|
joker
Global Moderator
member is offline
Gender:
Posts: 157
|
|
Re: little problem with file selection dialog
« Reply #11 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. 
|
|
Logged
|
|
|
|
pierscintilla
New Member
member is offline
Gender:
Posts: 30
|
|
Re: little problem with file selection dialog
« Reply #12 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) 
|
|
|
|
Alincon
Full Member
member is offline
Posts: 147
|
|
Re: little problem with file selection dialog
« Reply #13 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.
|
|
Logged
|
|
|
|
Richard Russell
Administrator
member is offline
Posts: 1348
|
|
Re: little problem with file selection dialog
« Reply #14 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.
|
|
|
|
|
