|
This looks like homework.
Create an event handler for the first button and in the event handler break out if the second button is pressed.
You should be able to work the rest out yourself otherwise you will not learn.
Elaine
The tigress is here
|
|
|
|
|
|
If it's a true infinite loop, it is unexitable.
Good music: In my rosary[^]
|
|
|
|
|
for UZMA..
//Declare these in the class header file...(.h)
static UINT runLoop(LPVOID p);
void runLoop();
///Put this in the implementation file....(.cpp)
UINT UZMAPPDlg::runLoop(LPVOID p)
{
UZMAPPDlg * me = (runLoop *)p;
me->runLoop();
return 0;
}
void UZMAPPDlg::runLoop()
{
do
{
///UZMA's story
}while(true)
}
in the click events(by double-clicking on the buttons!!), put
void UZMAPPDlg::OnButton1()
{
CWinThread cwt=AfxBeginThread(runLoop, this); //Start your loop
}
void UZMAPPDlg::OnButton2()
{
////Manipulate your cwt Object... here , resume,close etc
}
hope it'll work
regards,
vivek
|
|
|
|
|
Just have the nearly infinite loop terminate on a flag being set. Inside the loop pump the message queue. In the command handler for the other button, set the flag.
There is no need to create threads to do this.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Tim Smith wrote:
There is no need to create threads to do this.
if he doesn't, his GUI will be frozen...
TOXCCT >>> GEII power [toxcct][VisualCalc]
|
|
|
|
|
Thus the requirement to pump the message queue. How do you think programs did it prior to having threading?
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Why the following snippet causes runtime error and got prompt for"Unhandled exception...stack overflow"?
#include <iostream>
#include <stdio.h>
using namespace std;
class A
{
public:
A(){}
~A(){cout << "Leaving A" << endl;exit(1);}
};
A a;
int main()
{
}
|
|
|
|
|
Works without runtime error under Visual C++ .NET 2003
|
|
|
|
|
Mark Petrik Sosa wrote:
Works without runtime error under Visual C++ .NET 2003
I work under Visual C++ 6.0.
|
|
|
|
|
I think it is because it is a global object, and when you call exit(), it calls the global objects's destructor, which causes an endless loop.
Make it a local object, and it runs with no problems.
Remove the exit(1) call from the objects's destructor.
I am still confused.
this is this.
|
|
|
|
|
khan++ wrote:
I think it is because it is a global object, and when you call exit(), it calls the global objects's destructor, which causes an endless loop.
Yeah, I guess you're right!
|
|
|
|
|
i don't understand why just because it is global, the constructor can't be called correctly...
i don't understand either why calling a function (the constructor here) would enter an endless loop...
sorry, i didn't see the ending exit(1) on its destructor...
TOXCCT >>> GEII power [toxcct][VisualCalc]
|
|
|
|
|
Part of the startup and shutdown process of an image in C/C++ is to execute init and exit vectors. These vectors contain pointers to code that performs many functions including global object construction and destruction. Thus, the calling of exit can cause the exit vectors to be executed again which in turn causes the destructors to be called again.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Hi, as you 've probably guessed I tring to create a dll and use it in another program. So I've search some articles and I 've found a few interesting things. However when I try to execute a simple program it doesn't seem to work. Let's be a bit more specific.
<br />
#include "stdafx.h"<br />
#include "greet.h"<br />
#include <cstdio><br />
<br />
BOOL APIENTRY DllMain( HANDLE hModule, <br />
DWORD ul_reason_for_call, <br />
LPVOID lpReserved<br />
)<br />
{<br />
switch (ul_reason_for_call)<br />
{<br />
case DLL_PROCESS_ATTACH:<br />
case DLL_THREAD_ATTACH:<br />
case DLL_THREAD_DETACH:<br />
case DLL_PROCESS_DETACH:<br />
break;<br />
}<br />
return TRUE;<br />
}<br />
<br />
GREET_API int ngreet=0;<br />
<br />
GREET_API int fngreet(void)<br />
{<br />
return 42;<br />
}<br />
<br />
Cgreet::Cgreet()<br />
{ <br />
return; <br />
}<br />
<br />
void Cgreet::run(int arg)<br />
{<br />
printf("Hello World!\n");<br />
}<br />
The above code is produced by VS 7.1 when asked to create a new win32 console project and dll is selected. I 've also added another method to the class created. I also give you the header file VS created.
<br />
#ifdef GREET_EXPORTS<br />
#define GREET_API __declspec(dllexport)<br />
#else<br />
#define GREET_API __declspec(dllimport)<br />
#endif<br />
<br />
class GREET_API Cgreet {<br />
public:<br />
Cgreet(void);<br />
<br />
void run(int arg);<br />
};<br />
<br />
extern GREET_API int ngreet;<br />
<br />
GREET_API int fngreet(void);<br />
Well now I create a simple win32 console project with the following code
<br />
#include <cstdio><br />
#include <windows.h><br />
<br />
int main()<br />
{<br />
HMODULE hdll = LoadLibrary("greet.dll");<br />
if (hdll != NULL)<br />
{<br />
typedef int (*PFUNC)(void);<br />
<br />
PFUNC greet = (PFUNC)GetProcAddress(hdll, "fngreet");<br />
if (greet != NULL) {<br />
printf("greet.dll returned: %d!\n", greet());<br />
}<br />
else<br />
printf("Loading function 'fngreet' failed!\n");<br />
}<br />
else<br />
printf("Loading library 'greet.dll' failed!\n");<br />
}<br />
The output of execution is:
'Loading function 'fngreet' failed!\n'
I 've also seen in another post someone asked functions like "_fngreet" but that also didnt work. What am I doing wrong? Looking the code with the debugger I see in my main program that hdll pointer gets a weird address.
hdll 0x10000000 {unused=9460301 } HINSTANCE__ *
That's what the debugger says about hdll and of course greet fpointer is null.
Another question, let's say that I manage to get the function pointer loaded dynamicly. How will I load the Cgreet class? Does GetProcAddress works also for classes? What about variables?
That's all I guess!
Cheers, Themis
|
|
|
|
|
Your GetProcAddress on "fngreet" doesn't work because it's real name isn't fngreet, C++ uses decorated functions so you will get something different which will change if you add/remove arguments, change types. You can use Dependency Walker to see what the real name is and use that. It's recommended to use C linkage instead which will make your GetProcAddress work. Declare the function using extern "C".
#ifdef GREET_EXPORTS<br />
#define GREET_API extern "C" __declspec(dllexport)<br />
#else<br />
#define GREET_API extern "C" __declspec(dllimport)<br />
#endif
You cannot use GetProcAddress to return a class, however you can create a function which returns a class and use that function.
|
|
|
|
|
A strange problem, programmed to modify style for owner draw can't p
The CMyComboBox is derived from MFC's CMyComboBox,
I have modify style to realize owner draw for CMyComboBox as follows:
First, I do it at subclass the combobox,
void CMyComboBox::PreSubclassWindow()
{
ModifyStyle(0, CBS_OWNERDRAWFIXED|CBS_HASSTRINGS);
CComboBox::PreSubclassWindow();
}
Further, I do it at Create the combobox,
void CMyComboBox::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
lpCreateStruct->style |= CBS_OWNERDRAWFIXED | CBS_HASSTRINGS;
if (CComboBox::OnCreate(lpCreateStruct) == -1)
return -1;
return 0;
}
Ok, I have run the program, however that cannot into the DrawItem and MeasureItem which's areadly overridden.
But there is successful When I had modify resource associated with the CMyComboBox that has add special styles for owner drawing :
CBS_OWNERDRAWFIXED | CBS_HASSTRINGS
Any ideas ?
|
|
|
|
|
Modifing CBS_OWNERDRAWFIXED in PreSubclassWindow won't work, you can't change that style once the control is created. It's probably not working in OnCreate because you have one of the other "normal" styles flagged. Try unsetting them:
lpCreateStruct->style &= ~(CBS_DROPDOWN | CBS_DROPDOWNLIST | CBS_SIMPLE);
lpCreateStruct->style |= CBS_OWNERDRAWFIXED | CBS_HASSTRINGS;
|
|
|
|
|
I have individual step into the PreSubclassWindow that make sure it has good work.
I try to unsetting them which mentioned above, Only a bit changes as follows:
void CTTComboBox::PreSubclassWindow()
{
ModifyStyle(CBS_DROPDOWN | CBS_DROPDOWNLIST | CBS_SIMPLE, CBS_OWNERDRAWFIXED|CBS_HASSTRINGS);
CComboBox::PreSubclassWindow();
}
It still hasn't work?
|
|
|
|
|
Override OnCreate, CBS_OWNERDRAWFIXED is not a style you can force upon an already created control. Just like you can't transform a push button into a radio button without destroying it and creating a new one. Modifing styles in PreSubclassWindow is too late as the window has already been created.
|
|
|
|
|
Pardon me,
Here I only use DDX_Control method to subclass the Combobox in DoDataExchange function in specified dialog without OnCreate method to create the Combobox control, thus I seem must modify the style CBS_OWNERDRAWFIXED at PreSubclassWindow function. How you think that?
|
|
|
|
|
In the resource editor set the combobox's owner draw property to fixed.
|
|
|
|
|
Yes, I had done in Resource-editor, but I haven't still understand why don't via programmed to change it.
|
|
|
|
|
Forgive me, I don't know exactly what your asking or what your trying to do. Your English comes out a little ambiguous. Let me guess, you want to have a combobox that is dynamic in that sometimes it might need to be owner drawn, and sometimes you just want to let windows do this. Unfortunately this isn't easy. Once the control is committed you cannot change swap it's owner drawn style. You'll have to get creative. Perhaps two controls, one ownerdrawn one default and only have one of these visible at a time. Or you can handle your own "default" style drawing in the owner drawn. Either way you're going to have to get your hands a little dirty. Good luck.
|
|
|
|
|
Thanks for lots of helps,
I only want to have a combobox that is dynamic created or subclassed, and only by means of programmed to operate these.
Ok, to create a combobox and add the style CBS_OWNERDRAWFIXED or CBS_OWNERDRAWVARIABLE in the OnCreate function preprocessing. that will be successful without question,
but to subclass a combobox and do additional the style in PreSubclassWindow functon. that will be failed.
I haven't know whether the problem has been clearly described...
|
|
|
|