|
-=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
|
|
|
|
|
sheesh i havnt done asm coding in a while now so i dont have any sites off hand but there are loads of them
u can either do inline asm in vc++ i think or get masm (which is a free dnload from ms i think)
how to do chip specific stuff? get the data sheets from the chip makers and plow thru it
hope this helps
"traffic lights are for people who can't make their own decisions"
biz stuff about me
|
|
|
|
|
OK .. I have VC.NET,
I'm working on a CAS system and I'm writing a runtime compiler. It's working fine with standard routines, but I was thinking of implementing SSE routines. But I dunno how...
--------
Dave
|
|
|
|
|
I think that the new Visual C++ 2003 should support some options for allowing the SSE/SSE2 instruction set. But I have it only from marketing blabla on Microsoft's site...
|
|
|
|
|
I took over development of a project that is a client/server design. When an order is accepted on the server an exception is thrown. This exception only happens in a release build and unfortunately has a vague message box saying "The server through an exception". How does one nail down where this exception is happening?
The only information that I have when running the app through Visual C++ 6.0 is
"First-chance exception in Inforemer.exe (KERNEL32.DLL): 0x80010105: (no name)."
Can I use this information to deduct where the exception is thrown? Otherwise how else would I track it down?
Cheers,
Clint
|
|
|
|
|
try generating .pdb files. Usually there is Dr. Watson on the server if you have pdb it could be able to safe call stack. There is also debugging tools from Microsoft (not VC studio) with the small footprint, it is safe to put on the server. The major problem you have to overcome is to setup debugger to create dump when 0x80010105 happens. If you can debug the server on the local computer you can just use VC debugger, where you can actually step through the code (even release, with some limitations).
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
