|
OK,
if I'm getting it right, you would like to access member-variables
that reside in one of your classes while you are processing a method
that is a member of another class.
At first:
Classes don't 'have' variables in terms of allocating memory for them. These are only declarations.
If you want to assign values to member-variables you have to create an object of that specific class,
or you have to declare these variables 'static'.
To set an example (guess we are inside the Foo class):
// if you want to get information that a user has entered in a dialog
void Foo::OnFoo()
{
// create your object
FooDlg dlg;
// show it
dlg.DoModal();
// access its members
m_foo1 = dlg.foo1;
m_foo2 = dlg.foo2;
}
// if you want to show some of your information in a dialog
void Foo::OnFoo()
{
// create your object
FooDlg dlg;
// continue initialization
dlg.m_calledFrom = this;
// while FooDlg::m_calledFrom is declared as Foo* m_calledFrom; in the public section of your FooDlg class
// show it
dlg.DoModal();
}
I hope, I didn't miss the point...
Regards
|
|
|
|
|
Hello,
MFC embeds the WinMain function so you don't have to mess with the dirty WIN32 API.
I don't know what kind of data you need to access from what place, but it seems to me that you have trouble with encapsulating data.
It is not a good idea have public member variables in a class. This way, you can never safely assume what value the variable has or when it is safe to write a value to it.
Anyway, if you can explain us from which class you want to access what data in what class, and provide (example) code, we can do more for you.
Behind every great black man...
... is the police. - Conspiracy brother
Blog[^]
|
|
|
|
|
I'll try to explain as best I could. I created an SDI app with the wizard. I need to run an infinite loop (until the user closes the app) to repeatedly call various classes/objects. My first problem is I don't know where to put this loop in MFC, with old c++ I usually put somewhere in main() or such. In my app I have for example an intersection class (represents a simulated traffic intersection) which have various functions and variables. When u click file->new in my app I open up wizard-like dialogs which ask u about how u want the simulation etc. During this time I need to store these values and then later when the simulation begin use these values again. Thus in this wizard-like MFC-dialog class (which handles all the controls) I need to somehow store the enetered/selected values using that intersection class/or object of it, but must also retrieve these values later on from say that infinite loop.
Sorry for all the text.
|
|
|
|
|
Hi,
don't care about the message loop in classes you derived from CWnd.
If you are new in MFC, it might be easier to start a dialog-based application with the wizard.
Just put some edit-controls on it (one for each of your variables) and a button named 'Start' (to start your simulation).
Use the class-wizard (by right-clicking on your controls) to add member-variables and callback-methods to your dialog-class.
In your OnStart() handler call UpdateData(TRUE) to get the entered data into your member-variables, and UpdateData(FALSE) to show the content of your member-variables in the related controls.
I guess the whole stuff you have been asking for happens within
BEGIN_MESSAGE_MAP(CMyDlg, CDialog)
END_MESSAGE_MAP()
and inside the CMyDlg::DoDataExchange(CDataExchange* pDX) method.
Don't care about that code. Just let the class-wizad do that job for you.
Regards
|
|
|
|
|
Depending on your simulation, you should think about modeless dialogs and worker threads...
|
|
|
|
|
When you start (run) a dialog-based application, two objects are created automatically (guess your application is named MySim):
CMySimApp theApp; // this is a global object
CMySimDlg dlg; // this happens within CMySimApp::InitInstance()
You can find this code in the MySim.cpp file.
The message loop of CMySimDlg dispatches all your messages.
You may use all your former global valiables as member-variables of the CMySimDlg class.
Does it help ?
|
|
|
|
|
Thanx. I've already made an SDI app which took a while already, I don't think I should go back to a dialog-based app though.
Thanx anyway
|
|
|
|
|
Ouch .. NOOOOOOO ...
MFC apps are WINDOWS apps, not console apps.
The idea of an infinite loop in main cannot be used in a windows app, since a windows app is itself a loop.
You'll stuck your app, whith an infinite loop, pushing the CPU at 100% for ever, with the only chance, to the user, to kill it.
I suspect your real problem is that you're trying to do with MFC what you ususally do with traditional console application. That's not the way to go, with windows programming.
With MFC, consider this as starting points:
- CYourApp: public CWinApp has global linkage and exist for all the application life. Make its instance (usially a CYuourApp theApp varialble) to have global scope (by declaring it as external in a header included by all files - stdafx.h is good) and you can put any member in it and access it from everywhere.
- virtual CWinApp::Initinstance is called by the MFC embedded WinMain (like the main of traditional consoles) BEFORE the windows message looop is started. Any initialization code can be placed in the Initinstance override.
- Once the messageloop is started, the input devices (keyboard and mouse) are read by the system, and actions are sent as message to the active application's main window where are dispatched to the implementing C++ class member functions through a message map. You can respond to a message by doing any sort of calculation, but NEVER with an infinite loop, or the application will stuck.
- If you need to perform a lengthy operation through a loop, implement a loop like
whiile(your exit condition)
{
::MSG msg;
if (::PeekMessage(&msg, 0,0,0, PM_REMOVE) &&
!::TranslateMessage(&msg))
::DispatchMessage(&msg);
}
That is: give the system a chanche to manipulate input! (and remenber that input cannot be accessed with functions like getch() or cin::get etc. Input becomes messages deliveret to the main window)
(Another more sophisticated way is use a woker thread ... but if you're new to windows programming, multithreaduing is certinly not the starting point!)
- Output cannot be sent to any "stream": you must store it somewhere in your program, and them display it in the window by handling WM_PAINT (ususally with OnPaint)
- if you need a sort of "draw forever" program, you can instantiate a timer (::SetTimer)and respond to it in your main wiandow (OnTimer) with your loop's body (note BODY, not LOOP: the loop is in Windows, issuing the timer message)
Hope all this may help.
____________
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
Hi,
I need to add a feature to a program to play an audio CD.
However, the audio needs to be output via the soundcard, (not through the auto connector on the back of the CD player...)
has anyone got any tips on where to look for this?
(Main features requires, play a track starting at a certain time into the track, and retrieving track playback progress).
Thanks...
|
|
|
|
|
mci functions can help you.
it works easily, it have High level functions that accept text Commands.
Search it in msdn
|
|
|
|
|
Yes, I have just discovered that they do work without the audio cable connected,
My initial look at them suggested they didn't...
Thanks 
|
|
|
|
|
Hello,
I create some instances of a window based on CFrameWnd inside a thread. The windows are created successful and I can show the windows. But after _endthread () all windows are closed and destroyed automaticly. Why that and what I should do ?
Example:
CViewDiffDlg *diffdlg = new CViewDiffDlg (); <br />
diffdlg->Create (NULL, "");<br />
diffdlg->ShowWindow (SW_SHOW);<br />
<br />
_endthread ();
Thank you for helping and ideas
Stephan
|
|
|
|
|
I think you can send a message to the main thread to create the windows for you, and give the pointer back to your thread, so you can do whatever you want with it. That way the created windows should not die with the thread.
this is this.
|
|
|
|
|
Thank you for the answer, but
that don't solve my problem.
I've try your solution before I write the question to CP. The effect is the same. Window(s) are created and I see all what I want, but if the thread is closed, all windows are destroyed.
I don't need the window pointer anywhere. The window should be open and process his messages. Thats all.
Any other ideas
Best regards
Stephan
|
|
|
|
|
Hello...
The problem is that you create Windows inside from a worker thread which can produce unexpected situations...
You shouldn't directly create and manipulate gui objects in a worker thread...
Try to create and manipulate the window in the main thread...
F.E.: Create custom user messages and send them to mainframe.
like: #define WM_CREATEFRAME WM_USER + 200
#define WM_UPDATEFRAME WM_USER + 201
#define WM_DESTROYFRAME WM_USER + 202
in your worker thread:
void CMainFrame::workProc(LPVOID data)
{
// main window
CMainFrame *fr = static_cast<cmainframe*>(data);
::PostMessage(fr->m_hWnd,WM_CREATEFRAME,NULL,NULL);
while(anyThing)
{
// do a lot of calculations
::PostMessage(fr->m_hWnd,WM_UPDATEFRAME,NULL,NULL);
::Sleep(10);
}
::PostMessage(fr->m_hWnd,WM_DESTROYFRAME,NULL,NULL);
}
The mainframe process the custom messages and do the work on gui objects.
Best regards from germany
|
|
|
|
|
Thank you for the answer,
the idea is good but it doesn'nt solve the problem. Sh*t.
In my case I call SendMessage instead of PostMessage, because the thread should wait until window creation process is finished. If I debug and stop execution before I call _endthread() I see my window in the tasklist. After _endthread() window is killed.
Greetings back from germany to germany
Stephan
|
|
|
|
|
Yo baby yo baby yo
It works. Your solution was good. I had a mistake in the MessageMap.
Thanks to all for helping
Stephan
|
|
|
|
|
I don't have any problem with MFC dialogs. Maybe you need to look into the message pump in CWinThread::Run to see what happens when a main window of an MFC thread closes.
http://blog.joycode.com/jiangsheng
http://blog.csdn.net/jiangsheng
Command what is yours
Conquer what is not
---Kane
|
|
|
|
|
Thank you for the answer,
To try this, I must rewrite my code, because I don't use CWinThread now. I'm from "old school" like using _beginthread () with global Threadfunctions. And so a function should terminate intern via _endthread() (extern TerminateThread()).
I think, here is my problem, because the documentation describes, that _endthread() will clear up all objects from stack (and may be from heap too) they are created inside the thread.
I will try your sugestion with the message pump. May be I can see some mistakes.
Stephan
|
|
|
|
|
MFC thread state is needed by MFC objects. You need begin the thread with AfxBeginThread.
http://blog.joycode.com/jiangsheng
http://blog.csdn.net/jiangsheng
Command what is yours
Conquer what is not
---Kane
|
|
|
|
|
Yo baby yo baby yo
It works. The solution of HumanOsc was good. I had a mistake in the MessageMap.
Thanks to all for helping
Stephan
|
|
|
|
|
Hello again...
My solution is based on the great Articel from Joseph M. Newcomer:
http://www.codeproject.com/threads/usingworkerthreads.asp[^]
This is a very nice Introduction about worker threads.
Be carefull about SendMessage, it can also produce unexpected situations like a deadlock from your app...
Always prever the use of PostMessage to provide a safe gui access.
But Sometimes it's recommend (before or after the end of a worker thread) to get sure thats no (old) messages exists in the message queue.
In this situations use PeekMessage, GetMessage and DispatchMessage in main thread to remove (process) all old Message from Queue...
Best regards... 
|
|
|
|
|
I am searching for the location of the strcmp function so that i may be able to dynamically load it.
In which dll does it reside?
In which dll's do c-runtime libraries reside in general?
|
|
|
|
|
|
If you are programming in C/C++, you would be hard pressed to not already have that DLL loaded (unless you link statically).
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
