|
ok here we go 
in ur dialog box button message handler have something like:
PostMessage(AfxGetMainWnd(),WM_USER+10,0,0)
in ur main window have a message map entry for that message that processes the button click
just remember ur getting the message in the dialog from when the button is clicked and sending a message to another part of ur app to deal with it
"traffic lights are for people who can't make their own decisions"
biz stuff about me
|
|
|
|
|
thanks Lauren. i get what u explaind.
but when i use something like this :
<br />
void CDialog::OnBnClickedButton1()<br />
{<br />
AfxGetMainWnd()->PostMessage(WM_USER,0,0);<br />
}
it send message to CMainFrame Class. i have to Captute this Message in CDemoView.
it seems that this is the Routine Usage of Capturing messages of a Button and there is Something Wrong with me.
isn't it ?
|
|
|
|
|
no theres nothing wrong with u
i used to get confused as hell when i was learning mfc and all the message maps and that stuff
hmmmmm i still do sometimes
if u have an understanding of the big picture it all falls into place gradually
yes ... capture the message u sent urself in the mainframe and do the processing there
"traffic lights are for people who can't make their own decisions"
biz stuff about me
|
|
|
|
|
duh its an sdi app
AfxGetMainWnd() should be the main window of ur app??
unless im getting very confused??
CDemoView* pView = (CDemoView*)AfxGetMainWnd();
"traffic lights are for people who can't make their own decisions"
biz stuff about me
|
|
|
|
|
u speak so beautiful lauren 
thanx a lot. ![Rose | [Rose]](https://www.codeproject.com/script/Forums/Images/rose.gif)
why don't submit a better photo of yourself with a better Quality ? 
Best Regard
|
|
|
|
|
-=Ehsan-de-Burge=- wrote:
u speak so beautiful lauren
now THATS a first
thank u
"traffic lights are for people who can't make their own decisions"
biz stuff about me
|
|
|
|
|
unfortunately this also Creats an Object of CMainFrame!!!
CDemoView* pView = (CDemoView*)AfxGetMainWnd();
|
|
|
|
|
in ur debugger it will show as a mainframe but i just tested it in a quick app i built and the cast ptr is a ptr to the main view window
from a dialog i did:
CXView *pView = (CXView*)AfxGetMainWnd();
then:
pView->SomeViewClassFunction();
and it worked fine
???
"traffic lights are for people who can't make their own decisions"
biz stuff about me
|
|
|
|
|
It's long but it works:
Crate the dialog with the wizard and then crate dialog from that resorce IDD_!
Show the dialog!
Handle the Events of that Dialog Box in same Class and from there change what you want in class CDemoView, but you will need a global pointer of CDemoView in order to use it in Dialog Box functions!
|
|
|
|
|
uandrej wrote:
but you will need a global pointer of CDemoView
Exactly!!
but how can i define a Global pointer to CDemoClass ?????
is it possible??
|
|
|
|
|
In the begining of CDemoView *.cpp file declare global variable as
CDemoView* gCDemoView = NULL;
At the end of CDemoView constructor write
gCDemoView = this;
In the end of CDemoView destructor reset the pointer to NULL so you would know that no
longer exist
gCDemoView = NULL;
Now you can use that pointer anywhere in you code!!
uandrej
|
|
|
|
|
Using global variables in an object oriented code seems an heresy and a dirty way to me. Just my 2 cents.
Angels banished from heaven have no choice but to become demons
Cowboy Bebop
|
|
|
|
|
I'm not sure you need a global pointer, MFC gives all the methods needed to access its objects.
I suppose you are using the document-view architecture, and CDemoView is the view class of the application.
You can get a pointer on your main frame using
CMainFrame *pMyFrame = (CMainFrame *)AfxGetApp()->m_pMainWnd;
Your app being SDI, you can get the active view from the main frame using:
CDemoView *pView = (CDemoView *)pMyFrame->GetActiveView();
(because when using print preview the active view may be the preview view instead of your view, you should perhaps make the following test
CDemoView *pView = (CDemoView *)pMyFrame>GetActiveView();<br />
if(!pView || pView->IsKindOf(RUNTIME_CLASS(CDemoView))<br />
return;
Another way, perhaps safer, is to get the active document from the MainFrame (CDocument *CFrameWnd::GetActiveDocument) and then, from the document, accessing the view(s) it may own (CDocument::GetFirstViewPosition, CDocument::GetNextView)
HTH,
K.
Angels banished from heaven have no choice but to become demons
Cowboy Bebop
|
|
|
|
|
oh my goodnesses that's what i was searching forrrrrr
ive got ittttt
thank youuuuuu
 ;);););)
|
|
|
|
|
My pleasure
It's seems you have some troubles with keys staying blocked on your keyboard, or a funny accent
Angels banished from heaven have no choice but to become demons
Cowboy Bebop
|
|
|
|
|
but i think it's obvious that it's coz of my Bad English not Accent
thanks any way 
|
|
|
|
|
|
so i wanted to use a dll for certain functions in my app so that i could update that part without changing the rest and at the same time not make the main app bigger than it had to be by not requiring the dll stuff unless someone wanted that functionality
now it seems if i want dialog boxes in the dll i have to link it with mfc and as im using a static linked mfc in the main app to make the install easier for the end users it would make sense to use a statis link in the dll for the same reason
errrrr then i get 2 copies of mfc and a huge download???
does this mean i have to dynamically link with mfc for both parts of the app to achieve what i want? kinda silly if u ask me or maybe im missing something here?
"traffic lights are for people who can't make their own decisions"
biz stuff about me
|
|
|
|
|
lauren wrote:
then i get 2 copies of mfc and a huge download???
Well, technically you're not gonna get 2 copies of all the MFC classes inside the app and dll. Each one is only get what it uses from MFC. So yes, there will be duplication of MFC code in each one but it won't be all the MFC code.
I'd recommend dynamically linking with MFC for the app and DLLs, so that the MFC stuff is shared. Just make sure to install the MFC DLLs in the same folder as the app and DLL, and you shouldn't have any versioning problems.
Another alternative is to dump the whole separate DLL idea and just make the app bigger. After all, who cares? It's either ship one bigger app or a slightly bigger app plus a DLL.
Regards,
Alvaro
Well done is better than well said. -- Benjamin Franklin
(I actually prefer medium-well.)
|
|
|
|
|
Alvaro Mendez wrote:
Another alternative is to dump the whole separate DLL idea
thats what i kinda figured too
sheesh i loved the days when u could do code overlays
"traffic lights are for people who can't make their own decisions"
biz stuff about me
|
|
|
|
|
Switch to .NET lauren, it's easier over here... 
I don't know whether it's just the light but I swear the database server gives me dirty looks everytime I wander past.
-Chris Maunder
Microsoft has reinvented the wheel, this time they made it round.
-Peterchen on VS.NET
|
|
|
|
|
Depending on what you're doing in the DLL, you might be able to avoid using MFC in it at all - this is more work for the GUI stuff, but if you don't have too much of that it might be a solution.
Or just dynamically link. This week's poll aside, it usually causes only minor support headaches and hair-pulling, especially if you're careful to use the latest versions of MFC and do *lots* of testing...
---
Shog9
The siren sings a lonely song - of all the wants and hungers
The lust of love a brute desire - the ledge of life goes under
|
|
|
|
|
Hi!
How can I write processor specific code, like SSE/SSE2??
--------
Dave
|
|
|
|
|
either use asm code
or get a compiler that supports it
afaik
"traffic lights are for people who can't make their own decisions"
biz stuff about me
|
|
|
|
|
any resoures?
--------
Dave
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
