Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » FileSel&FileList, Path » File Chooser closing
File Chooser closing [message #30510] Wed, 05 January 2011 23:50 Go to next message
nlneilson is currently offline  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 Go to previous messageGo to next message
dolik.rce is currently offline  dolik.rce
Messages: 1789
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

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 Smile But that is not really related to the problem Wink

Best regards,
Honza

Re: File Chooser closing [message #30526 is a reply to message #30520] Thu, 06 January 2011 15:52 Go to previous messageGo to next message
nlneilson is currently offline  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 Go to previous messageGo to next message
dolik.rce is currently offline  dolik.rce
Messages: 1789
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

I still can't reproduce what you describe... Unfortunately I don't have MSC to test (actually I don't even have windows Smile ). 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 #30529 is a reply to message #30528] Thu, 06 January 2011 20:01 Go to previous messageGo to next message
nlneilson is currently offline  nlneilson
Messages: 644
Registered: January 2010
Location: U.S. California. Mojave &...
Contributor
Thanks Honza

I tried it with the changes and it works OK and clicking Cancel or the red X exits the file chooser the way it should.

Looking at my code it is a bit of a mess, I had renamed another app and made changes from there. Probably 90% of the variables are not used in this app.

There are a few things noticed so far:
The file chooser window is partially off of the upper left of the screen, hard to move it.
The .cfg file is saved in the directory of the files opened, it should be in the same directory as the .exe.
All minor and can be easily changed.

The EditFields for the files opened are editable for the only purpose to copy, no data will be input there manually but the ability to input the file name will be handy in another app.
The only data that will be manually input is the base file location, extra error handling which was done in another app can be added.

I have not tried this in Linux yet with wine, if there is a glitch there using FileSelector then FileSel will work fine.

I noticed several other changes that will be improvements.
It will take me some time to understand all the changes.

The problem I had exiting the file chooser is solved.

Neil
Re: File Chooser closing [message #30532 is a reply to message #30528] Fri, 07 January 2011 00:42 Go to previous messageGo to next message
nlneilson is currently offline  nlneilson
Messages: 644
Registered: January 2010
Location: U.S. California. Mojave &...
Contributor
dolik.rce wrote on Thu, 06 January 2011 17:39

I still can't reproduce what you describe...


That was not a good example as the problem only happened about half the time.

Here is an example that has the problem every time after the first time a file is opened. File->Save/Exit will save the recent_dir to a .cfg file.

Also included in the .zip is ReplayTest.txt. This file can be opened and all this example does is read the first ten lines with sleep in between and displays that line in the top EditField. I had to include the thread so the display is visible when it is running, other than that it is as simple as I could make it and still show the problem.

I have not made the changes from your previous example yet but will.

THISBACK1 rather than THISBACK ??
(Ctrl* ctrl) ??
*ctrl<<=fn0.Get(); ??
They work but I am not familiar with these.

Neil


  • Attachment: Replay.zip
    (Size: 2.62KB, Downloaded 318 times)
Re: File Chooser closing [message #30533 is a reply to message #30532] Fri, 07 January 2011 01:54 Go to previous messageGo to next message
nlneilson is currently offline  nlneilson
Messages: 644
Registered: January 2010
Location: U.S. California. Mojave &...
Contributor
I made some changes to the .cpp but apparently not enough.
The problem is still present.
  • Attachment: Replay.cpp
    (Size: 2.77KB, Downloaded 329 times)

[Updated on: Fri, 07 January 2011 02:02]

Report message to a moderator

Re: File Chooser closing [message #30536 is a reply to message #30510] Fri, 07 January 2011 11:20 Go to previous messageGo to next message
dolik.rce is currently offline  dolik.rce
Messages: 1789
Registered: August 2008
Location: Czech Republic
Ultimate Contributor

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 Go to previous message
nlneilson is currently offline  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

Previous Topic: Warning in FileSel
Next Topic: FileSel has classic Windows look since r2848
Goto Forum:
  


Current Time: Thu Mar 28 17:44:09 CET 2024

Total time taken to generate the page: 0.02015 seconds