|
That works if I just open the application and then do a File/New or File/Open but if I try to run an open verb on a data file, I get a "Windows cannot find file "Some file path", then the application window opens and the document shows. (The error message box remains somewhere in the z-order.
This does not happen if I don't initialize GDI+ until the CDocument Constructor is called.
|
|
|
|
|
Call Gdiplus::GdiplusStartup() in (CWinApp Derived Class)::InitInstance()
Call Gdiplus::GdiplusShutdown() in (CWinApp Derived Class)::ExitInstance()
|
|
|
|
|
That does not seem to like file open verbs. If I double click on a data file for that MFC application, I get an error "Windows cannot find file (Some file path)".
|
|
|
|
|
What are you talking about? What does GdiPlus have to do with file open verbs?
I created a test MDI application and replicated this behavior. It appears that the GdiPlusStartup causes a problem with DDE. The error is a child window of WindowsExplorer. Even more odd, if you exit the mdi app right after the GdiPlusStartup() call, the error still happens.
This appears to be a Microsoft bug.
modified on Monday, August 17, 2009 3:16 PM
|
|
|
|
|
Joe Woodbury wrote: What are you talking about? What does GdpiPlus have to do with file open verbs?
Thread timing maybe. I dunno. I get the Windows error when I try to double click on an MDI Doc/View application data file when I try to initialize GDI+ where you advised.
It's a mystery to me as well but it is happening.
|
|
|
|
|
Hmm, threw a quick MDI app together and am seeing what you describe. This is a true head scratcher.
|
|
|
|
|
I think I tried suppressing the background thread before and failed but I decided to try this again. This MSDN article appears to discuss the problem but I get a runtime error if I try to implement their code snippet.
Special CWinApp Services[^]
Here on Code Project, this individuals approach to suppressing the background thread (when using GDI+ from a DLL) appears to make the problem go away. I'm not sure what is different about the two since InitInstance is called before CWinThread::Run.
Using GDI+ with MFC or native C/C++[^]
Anyway, thank you for taking some time out to investigate this. We'll see if this approach holds together.
|
|
|
|
|
I got the first solution to run in VS 2005 SP1 with a bare bones app.
I need to store this solution away in my bag-o-tricks.
|
|
|
|
|
Good Monday! (yeah, there goes the sympathy votes!)
I have a small dialog that let the user select one item out of around 250 items.
The items are grouped into logical categories; so I'm looking at doing something like
have two lists, one with the categories, and one containing the subsets represented
by the selected category. (i.e. a bit like the toolbar/command customize of VS2008)
Is there other new ways to present that kind of information ?
Thanks.
Max.
This signature was proudly tested on animals.
|
|
|
|
|
Would a simple tree control do the trick ? Because IMHO it looks better than having two separate lists.
|
|
|
|
|
Maximilien wrote: Is there other new ways to present that kind of information ?
Other: yes. New: probably.
You can put all the info in a single control with list and expansion capabilities, such as a TreeView. Here is an example[^]. It could start of in collapsed state, and expand when one of the pluses gets clicked, possibly collapsing any previous expansions.
[EDIT]link fixed]/EDIT]
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get.
Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
modified on Monday, August 17, 2009 10:49 AM
|
|
|
|
|
Example link is not opening, can you check once?
|
|
|
|
|
Link now fixed. Sorry for that.
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get.
Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
|
|
|
|
|
As a UI layout, in a small surface, I suggest a top combobox populated with categories
and a bottom checkedListbox having the same width and populated with the "selectable" items.
Of course you intercept the combobox selection change event and you refill the listbox with item
belonging to the new active category only.
Easy Profiler : a compile-time profiler for C++
www.potatosoftware.com
|
|
|
|
|
Doesn't that "hide" the categories to the user ? i.e. force him to click on the combobox ?
This signature was proudly tested on animals.
|
|
|
|
|
Yes that's true. But as I understood, the role of categories is here to aid with the selection process only.
The combox can show something as long as the following (MSWord options=>customize) :
http://farm3.static.flickr.com/2498/3830410758_5ea4f4e55a_o.png[^]
And there would be no problem.
If the space is really very very small, then you may need a " hierarchical checked combobox "
Good luck.
Easy Profiler : a compile-time profiler for C++
www.potatosoftware.com
|
|
|
|
|
A couple of ideas from iTunes
- The 'Grid' view, when you have the 'Artists' view selected, shows a grid containing all the artists. Double-click on that and you get a list view of all the artist's tracks, grouped into albums.
- The list view in iTunes shows all tracks (that's almost 13000 for me). There is a 'Search' field, which acts as a filter - if I want to find tracks which have some link to the text 'camera', I type 'camera' into the search field and get two tracks; 'Distant Camera' by Neil Young and 'The Camera Eye' by Rush
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Ever thought about a Tree Control?
Bram van Kampen
|
|
|
|
|
After creating some thread, I want to keep track of them in a vector
(vector<boost::thread> ), but it fail.
So I need to use vector<boost::thread*>, but in this way, I have to free them manually.
modified on Monday, August 17, 2009 9:16 AM
|
|
|
|
|
followait wrote: (vector<boost::thread> ), but it fail.
What do you mean by "it fails" ?
I never used boost::thread before but if you are getting a compilation error, it probably means that the class do not allow to make copies of an instance (e.g. they made the assignement operator and copy constructor private).
|
|
|
|
|
Cedric Moonen wrote: the class do not allow to make copies of an instance (e.g. they made the assignement operator and copy constructor private).
Exactly right - just like IOstreams
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Use a std::vector<boost::shared_ptr<boost::thread> > . That way you get a copyable object that manages its resources itself.
it makes a lot of sense for a thread object to be non-copyable[^] - just like it makes sense for an iostream to be non-copyable. When you have a link to a concept visible outside your program, you only want one object to manage it otherwise you could get contradictory scenarios happening, like one object killing the thread while another is trying to join the thread or something.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
But when using pointer, this still will happen.
Maybe things should be synchonized, but it'll be inefficient.
|
|
|
|
|
followait wrote: But when using pointer, this still will happen.
No it won't - you'll be copying the pointer, not the object it refers to.
followait wrote: Maybe things should be synchonized, but it'll be inefficient.
Really? I think not.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Stuart Dootson wrote:
No it won't - you'll be copying the pointer, not the object it refers to.
More than one pointers can do things than conflicts simultaneously in different threads.
Stuart Dootson wrote:
Really? I think not.
Agree, it's good to keep it simple for the fundamental concept. It can be encapsulated as needed.
|
|
|
|