|
|
Home » U++ Library support » FileSel&FileList, Path » File Chooser closing
File Chooser closing [message #30510] |
Wed, 05 January 2011 23:50 |
nlneilson
Messages: 644 Registered: January 2010 Location: U.S. California. Mojave &...
|
Contributor |
|
|
I searched but could not find an answer, I may just be missing something.
When the file choosing window is opened and without picking a file when the "Cancel" or red "X" is clicked to close the file chooser it opens a file. How can this window be closed without opening a file?
fn <<= Nvl(r_d, recent_dir);
if(fn.ExecuteOpen()){ // file chooser
Data<<=Value(fn);
r_d = fn;
recent_dir = ~fn;
}
Neil
[Updated on: Wed, 05 January 2011 23:51] Report message to a moderator
|
|
|
Re: File Chooser closing [message #30520 is a reply to message #30510] |
Thu, 06 January 2011 12:01 |
|
Hi Neil,
I failed to reproduce the problem you describe. The way you use ExecuteOpen() seems correct, it should return false when closing the window or hitting Cancel. I tested with GCC and with MinGW. Are you using FileSel or FileSelector? Maybe if you post a complete, compilable testcase that shows the wrong behavior we can figure out what is the problem...
Also, I don't really understand what are you trying to do with the r_d and recent_dir. Both fn and ~fn return the same thing, the difference being that once it is string, and the second is value, but in the end they are used in Nvl, so I deduce they are same type or they are converted to the same type upon use, so I don't see much sense to have them both But that is not really related to the problem
Best regards,
Honza
|
|
|
Re: File Chooser closing [message #30526 is a reply to message #30520] |
Thu, 06 January 2011 15:52 |
nlneilson
Messages: 644 Registered: January 2010 Location: U.S. California. Mojave &...
|
Contributor |
|
|
Attached is a .zip that has the full package for an app that has two instances of a file chooser.
FileSel or FileSelector?, Nvl?
I found an example that worked to get a file and have been using the same code since then.
What it does or how it does it I don't know, I could not find a help file that explained it.
I am using MSC9.
Neil
edit: removed .zip, bad example
[Updated on: Fri, 07 January 2011 00:13] Report message to a moderator
|
|
|
Re: File Chooser closing [message #30528 is a reply to message #30526] |
Thu, 06 January 2011 17:39 |
|
I still can't reproduce what you describe... Unfortunately I don't have MSC to test (actually I don't even have windows ). Maybe someone else out there could give it a try with MSC?
nlneilson wrote on Thu, 06 January 2011 15:52 | FileSel or FileSelector?, Nvl?
|
FileSelector uses windows API to open native windows file selector.
FileSel is pure U++ file selector dialog. It is typedefed to FileSelector on non-windows systems.
You can use FileSel on windows, but to be more user friendly I would choose FileSelector...
Nvl is a utility functions that checks if the first parameter is not Null. If it is, it returns the second argument, otherwise it returns the first one.
Anyway, for your needs, it is just fine to call something like void OpenBaseFile() {
fn1.ActiveDir(recent_dir);
if(fn1.ExecuteOpen()){ // file chooser
filename1 = fn1;
BaseFile<<=Value(fn1);
recent_dir = fn1.GetActiveDir();
}
}
In the attached file you will find even more elegant solution. I also fixed a couple of glitches in your code. All the changes are marked using a comment with my nick and explained.
Honza
|
|
|
|
|
|
Re: File Chooser closing [message #30536 is a reply to message #30510] |
Fri, 07 January 2011 11:20 |
|
Hi Neil,
The only problem I see in your code is that the work thread is started every time you call OpenFile(), while it should be called only when ExecuteOpen() returns true: void OpenFile(){
fn0.ActiveDir(recent_dir);
if(fn0.ExecuteOpen()){
FileEF<<=fn0.Get();
recent_dir=fn0.GetActiveDir();
work.Run(THISBACK(Work)); // <- moved here
}
//work.Run(THISBACK(Work));
} That might "look like" the file is opened even when you cancel the selection, because the replay happens unconditionally every time. Is that the problem you have? But that would not be problem in the other application you provided as example...
If there is something else, than I'm seriously puzzled. It might be MSC related, in which case, I have no chance to figure it out.
Honza
|
|
|
Re: File Chooser closing [message #30537 is a reply to message #30536] |
Fri, 07 January 2011 12:31 |
nlneilson
Messages: 644 Registered: January 2010 Location: U.S. California. Mojave &...
|
Contributor |
|
|
Hi Honza
That was the problem.
dolik.rce wrote on Fri, 07 January 2011 11:20 | That might "look like" the file is opened even when you cancel the selection, because the replay happens unconditionally every time. Is that the problem you have? But that would not be problem in the other application you provided as example...
|
"...because the replay happens unconditionally every time."
I was calling the work thread outside of the:
if(fn0.ExecuteOpen()){
...
}
The previous example did not use a thread. Even with 8 hours of data it only took a few seconds to merge.
There is a separate call to merge by clicking File->Merge so it was not automatic.
bar.Add("Merge Files", THISBACK(Merge));
If the file chooser was closed with "Cancel" without picking a file the variables for the out, base and roam files were still set even if the data in the EditField was deleted.
When the app was started the .cfg file set the (recent_dir) to when the app was previously run, opening the file chooser and closing with "Cancel" set whatever file was to be picked to that of the previous run, (recent_dir), and that was only when a file was not picked. Normally this would not be much of a problem but testing found this error.
I am used to something like if(fn0) and if(!fn0)
The if(fn0.ExecuteOpen()) added to my confusion.
Calling the work thread from inside the if() block fixed things.
I have two other apps with the same fix.
Much Thanks!
Neil
[Updated on: Fri, 07 January 2011 12:48] Report message to a moderator
|
|
|
Goto Forum:
Current Time: Fri Sep 20 10:04:08 CEST 2024
Total time taken to generate the page: 0.05602 seconds
|
|
|