|
Yeah, this sounds fine. Obviously an entity needs to exist which has pointers/references to the two classes which need to share data.
Steve
|
|
|
|
|
The two classes have some reference to the intermediary object, not the other way around.
However, if either class has a LOT of data, you would not want to keep copying that around. But then if they need to share a lot of data that frequently, neiher of the clients should possess the data in the first place - the data SHOULD reside in the intermediary object - a data repository object.
Each client then uses its own mechanism, or a parent object hooks everything up.
Typically, when a question like this is posed, I immediately think there is no or little separation of data from processing, and every system I have ever encountered that is made that way, suffers from upgrade and migration problems not too distant in its future.
People that start writing code immediately are programmers (or hackers), people that ask questions first are Software Engineers - Graham Shanks
|
|
|
|
|
how abt applying the friend class concept?
"faith, hope, love remain, these three.....; but the greatest of these is love" -1 Corinthians 13:13
|
|
|
|
|
I have a form where a user can/could type in a filename, the form also have a "..." button where she can press to load a CFileDialog to also type the filename and decide where the file will reside.
The question is,
Do I make the text field non-readonly so the user can type a filename ( with and without a full path ) and have a chance that the path is not well formed, forcing me to di extra validation; or make the text field read-only and only use the CFileDialog to "force" the user to have to press a button ( and sometimes wait a few seconds ) to only type in a filename ?
and if there's a prefered Microsoft User Interface Guideline for this issue, where can I have a look ?
Thanks.
M.
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
If its read-only, it makes it hard to cut-n-paste, as pasting into a CFileDialog doesn't do what you want it to. So I'd do a validation.
|
|
|
|
|
|
Hello,
If I look at all the applications that I use, I can type in a filename in every box that matches your description. So if there isn't a Microsoft guideline written down, there sure is an implicit guideline. So I would use the validation approach.
The validation isn't that hard to do: ::PathFileExists()[^] is all the validation you need.
Hope this helps. 
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
I can't stand path-type edit boxes that do not allow me to type/paste into them. Simply use PathIsDirectory() or PathSearchAndQualify() for validation.
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
|
|
|
|
|
|
Use this[^]. It's brilliant and does exactly what you need.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
|
hi
does any one know how to so using Visual c++.
thanks in advance
|
|
|
|
|
you post the same question 3 hours and 38 minutes ago; maybe the sound/wave experts that could help you did not come here yet.
but where is your problem ? recording ? analysing ?
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
Hi.
How can I implement a MRU as popup sub menu in a MDI application ?
Manosza.
-- modified at 16:16 Monday 23rd January, 2006
|
|
|
|
|
I have a C++ DLL that some other programs use. I set SetUnhandledExceptionFilter in the DLL to catch any application crashes. The application crashes, the DLL's ProcessDetach isnt called, but this filter function isnt called either. Any tips for debugging this problem?
thanks!
|
|
|
|
|
Maybe someone called ExitProcess? put a breakpoint in ExitProcess and track back the call stack..
|
|
|
|
|
__yb wrote: Maybe someone called ExitProcess?
If that is the case my DLL's ProcessDetach should be called right? Other possibility is TerminateProcess is called.
__yb wrote: put a breakpoint in ExitProcess and track back the call stack..
I will try this. Although I only have release version of the application - I am not sure if I am going to get the call stack to see.
thanks!
|
|
|
|
|
Maybe another module called SetUnhandledExceptionFilter and replaced your handler but isn't calling yours. It is unusual for a DLL to call this API - Normally you'd do this kind of thing in the .EXE. You could place a breakpoint inside SetUnhandledExceptionFilter and check for this.
Steve
|
|
|
|
|
Stephen Hewitt wrote: Maybe another module called SetUnhandledExceptionFilter and replaced your handler but isn't calling yours
How do we detect that? How do find out the currently set unhandled exception filters, if any?
Stephen Hewitt wrote: It is unusual for a DLL to call this API - Normally you'd do this kind of thing in the .EXE
Actually, it used to work earlier. Due to some changes this regressed. I only need tips to debug this.
Stephen Hewitt wrote: You could place a breakpoint inside SetUnhandledExceptionFilter and check for this.
As I said I already have a message box as the first statement in SetUnhandledExceptionFilter filter, and that doesnt come up. So I am assuming my filter isnt called at all 
thanks!
|
|
|
|
|
Brundiez wrote: How do we detect that? How do find out the currently set unhandled exception filters, if any?
I would use WinDBG as follows:
1. Start the process in question.
2. Type "bp kernel32!SetUnhandledExceptionFilter" in the command window.
3. Press F5.
4. When the breakpoint is hit look at the stack.
5. Goto step 3
This will show every call to SetUnhandledExceptionFilter made in the process. I would only pay attention to breakpoints that occur after your call to SetUnhandledExceptionFilter.
Steve
|
|
|
|
|
Hi,
I have a SDI application that I show a CListCtrl-derived control using the LVS_ICON style with a 24-bit color imagelist filled with 80x80 bitmaps to represent the items in the control. When I select an item in the control, it doesn't select properly. Only the text of the item is selected and it is gray as if the control doesn't have the focus. But the control does in fact have the focus. Why doesn't the item select properly, i.e., with a blue background?
Any help would be greatly appreciated,
Royce
-- modified at 12:47 Monday 23rd January, 2006
|
|
|
|
|
RoyceF wrote: I have a SDI application that I show a CListCtrl-derived control...
Are you using a CListView?
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
|
|
|
|
|
No, the parent of the control is the CFormView created by the CSingleDocTemplate constructor when the application is created.
|
|
|
|
|
To ascertain whether it is the actual list control or the parent object (CFormView) causing the problem, I would suggest creating a temporary dialog-based project that contains the same sort of list control. Populate the list control in exactly the same fashion. Does it behave the same as the one in the SDI project?
"The words of God are not like the oak leaf which dies and falls to the earth, but like the pine tree which stays green forever." - Native American Proverb
|
|
|
|
|
Ok, I did as you suggest. I get exactly the same behavior. The items select just the text and are a dim gray.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
