|
This article of mine has example code for displaying a metafile form the clipboard.
http://www.codeproject.com/useritems/dib_metafile.asp[^]
Roger Allen
Sonork 100.10016
This is a multiple choice question, choose wisely
Why did the hedgehog cross the road?
A: To show he had guts?
B: To see his flat mate?
|
|
|
|
|
Quick question: what is the major difference between bool and BOOL and when should I use one or the other?
- monrobot13
|
|
|
|
|
bool is a native type in C++, like int and float, and 'true' and 'false' are the only values it accepts (I believe you need to specifically cast an int, if possible at all). BOOL is generally a #define or typedef of an int, with TRUE and FALSE also being #defined
bool gives you better type checking on compilers that support it, BOOL will work anywhere but with weaker checking. if you can, use bool (VC6+ works fine with it)
|
|
|
|
|
Functionally, bool and BOOL are identical. bool should be preferred since BOOL is a legacy from a time when bool was not part of the language. It is necessary to use it with the Windows APIs, though, as I say, they are largely interchangable.
One difference though is that sizeof(bool) = 1 and sizeof(BOOL) = 4 (generally speaking).
This is particularly relevant when you need an array of boolean flags. For example,
bool lineChanged[2048];
takes 75% less memory than
BOOL lineChanged[2048];
|
|
|
|
|
bool is a true variable types just like int or float and takes values of true or false.
BOOL takes TRUE (defined as 1) or FALSE (defined as 0) or an integer value with 0 being false and non zero being true.
BOOL is a defined type of int. Therfore you can make a BOOL = int no problem and vise versa.
BOOL will aslo be 32 bits in size where as bool is supposedly only one bit in memory.
|
|
|
|
|
If your development is in the win32 environment, you should use "BOOL".
"BOOL" is a data type of win32, so we often use it. And "bool" is a C\C++ data type. If you are using a pure C\C++ compiler, you can use "bool". Now everything is ok. God bless you.
stanley
|
|
|
|
|
Im dipping my toe into the murky waters of i/o completion ports.
My app presently use threads to handle client connections , on for each connection. Naturally i now want to use i/o completion ports.
Internally i do a lot of database access using odbc. Is there any way to link a SQLExec statement to a completion port ? Theres lots of examples of using sockets but nothing about databases. Doing an async read still involves polling to test the status of the executing statement, which will still mean using multiple threads.
I cant believe theres not support for this but ,as ever, the MS docs are very light on the subject.
Dave
|
|
|
|
|
Dave-B wrote:
Internally i do a lot of database access using odbc. Is there any way to link a SQLExec statement to a completion port ? Theres lots of examples of using sockets but nothing about databases. Doing an async read still involves polling to test the status of the executing statement, which will still mean using multiple threads.
Simple multithreading suits your application which uses SQLExec, IOCP is for overlapped reads/writes with SQL does not support.
|
|
|
|
|
Norm Almond wrote:
Simple multithreading suits your application which uses SQLExec, IOCP is for overlapped reads/writes with SQL does not support.
As you state that SQL does not support overlapped read/writes, presumabley this means that IIS etc, are not truly scallable if the script uses database access  . Thats a real bummer in the real world, though as i will have to have multi threads 'hanging around' for the database to return results.
BTW thanks for your IOCP code.
Dave
|
|
|
|
|
With IOCP you have some worker-threads, normally I go for 2 - 4 four for each CPU in the machine.
If everything is running fast and not waiting for anything, your completion port only uses a single thread for each CPU, but if one of those threads is "suspended" waiting for disk I/O, a database or something else, and a new socket connection is opened, the completion port uses a new thread to handle that connection.
Basically IO Completion Ports is a mix between a threadpool and async. I/O 
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
I have a modal dialog box which has a tab control. During the dialog box's procedure I create three modeless dialog boxes for the display area of the different tabs. I used a common dialog box procedure for all three modeless dialog boxes (Q: Is this bad?). In the procedure for the three dialog boxes I call CreateSolidBrush for coloring the background of some controls. When I close the main (modal) dialog box I call DestroyWindow three times for each modeless dialog box. I process the WM_DESTROY message in the procedure for the three modeless dialog boxes and in it I call DeleteObject(hBrush). Does this cause a resource leak because CreateSolidBrush is called three times yet DeleteObject only once (even though it is the same handle to the brush) ?
|
|
|
|
|
Q: Is this bad?
On the contrary, it is the normal thing to do if the three dialog boxes look the same.
Does this cause a resource leak because CreateSolidBrush is called three times yet DeleteObject only once (even though it is the same handle to the brush) ?
Seems to me you're doing it in plain Win32 style, no MFC, right? If so, you're producing memory (or GDI) leaks, as there's only one copy of the HBRUSH object --previous brushes get lost on succesive calls to CreateSolidBrush. To avoid this, probably the simplest workaround is to have a count of how many instances of the dialog there are, initialize resources when the first one gets created and do the cleanup when the last one dies.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Thanks for the help, actually, I think I confused myself, I'll post the code for the modeless dialog procedure and maybe you can tell me if I am creating a resource leak or not?
This is the function for the three modeless dialogs:
BOOL CALLBACK InfoTabChildDlgProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam)
{
HBRUSH hControlBrush = CreateSolidBrush( RGB(170, 170, 213) );
int iStaticWindow;
switch(message)
{
case WM_CTLCOLORSTATIC:
iStaticWindow = GetWindowLong( (HWND) lParam, GWL_ID );
switch(iStaticWindow)
{
case IDC_MOVIENAME:
case IDC_CATEGORY:
case IDC_STATUS:
case IDC_LOCATION:
case IDC_NUMBER:
case IDC_TITLE:
case IDC_YEAR:
case IDC_DIRECTOR:
case IDC_TAGLINE:
case IDC_PLOT:
case IDC_GENRE:
case IDC_ACTORS:
case IDC_LANGUAGE:
case IDC_RUNTIME:
SetTextColor( (HDC) wParam, RGB(0, 0, 0));
SetBkColor( (HDC) wParam, RGB(170, 170, 213) );
return (BOOL) hControlBrush;
}
return TRUE;
case WM_INITDIALOG:
return TRUE;
case WM_DESTROY:
DeleteObject(hControlBrush);
EndDialog(hDlg, 0);
return TRUE;
case WM_COMMAND:
switch(LOWORD (wParam))
{
case IDC_UPDATE:
_beginthread(IMDbThread, 0, NULL);
return TRUE;
}
break;
}
return FALSE;
}
For the modal dialog box, when I want to end everything I have I call DestroyWindow(); 3 times, one for every modeless dialog. If the previous hBrush(es) are getting lost with each successive call, then how do I go about keeping count of how many instances of the dialog I have? Also, am I correct in thinking that the WM_CTLCOLORSTATIC message gets called before WM_INITDIALOG? In that case maybe I should call DeleteObject(); in WM_INITDIALOG.
|
|
|
|
|
Well, you're having massive resource leaks here: Every time InfoTabChildDlgProc is called (and it's called many times during the life of a dialog box) you create a fresh HBRUSH. The way to have one and only one brush is by defining hControlBrush as static. Also, by combinig this fix with the count of instances hack, you'll ge the following:
BOOL CALLBACK InfoTabChildDlgProc(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam)
{
static HBRUSH hControlBrush;
static unsigned int nCount=0;
...
case WM_INITDIALOG:
if(nCount++==0){
hControlBrush = CreateSolidBrush( RGB(170, 170, 213) );
}
return TRUE;
...
case WM_DESTROY:
if(--nCount==0){
DeleteObject(hControlBrush);
}
EndDialog(hDlg, 0);
return TRUE;
...
}Hope this helps, regards,
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Thanks a lot, this actually does help! I forgot about the good old static keyword. You made me a little paranoid though. In all my dialogs I have declared local variables, a lot of HWND's mostly to get a handle on controls. I don't suppose that is also creating a memory leak...right? Also, is it a good rule of thumb to declare handles that use Create... (like CreateSolidBrush) as static wherever they may be, eg. WndProc. One last question!: I am correct in thinking that WM_INITDIALOG get called once and only once, so that in my other dialogs I can call CreateSolidBrush without having to count how many instances of the dialog I have since it is only one?
|
|
|
|
|
I have two console programs. I am on a command prompt cmd.exe (fullscreen/windowed makes no diff) The simplified code is here for each program:
prog1:
main()
{
char *args[3];
args[0] = "prog2.exe";
args[1] = "abc";
args[2] = NULL;
printf("this is in prog1.\n");
_execv("prog2.exe",args);
exit(0);
}
... and prog2:
main()
{
printf("this is in prog2.\n");
getchar();
exit(0);
}
When I execute prog1, prog1 returns to the command prompt and interferes with prog2 by the input focus being on the command line. How can I keep the focus on prog2?
I can see no way around this! What can be done to keep the focus on the second running program? If I start prog1 without using cmd, it works fine, but this is not practical.
Thank you in advance ... this is driving me nuts!!!
|
|
|
|
|
Just an idea...
Try CreateProcess instead of _execv
- Anders
Money talks, but all mine ever says is "Goodbye!"
|
|
|
|
|
thanks for your response!
However, I have tried this and have gotten the same results. whether handles are inherited, etc etc I get the same results. I am amazed that no one else has run into this problem!
|
|
|
|
|
When using CreateProcess you are returned a process handle inside the LPPROCESS_INFORMATION parameter. Use this handle with WaitForSingleObject to wait for termination of prog2.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Thank you for your response...
I have considered your suggestion, but the example I have given merely simplifies a bigger problem. I have up to 175 or so different console apps which may be selected from a menu system. It does not seem practical to do this. However, I suppose a program which essentially protects all these from ever reaching the command prompt would be an option.
Wouldn't this behavior be classified as a bug? I have never seen this in DOS or OS/2.
The only other thing I can think of is thatthe command prompt uses a different in, out and error handle, but I do not see any way of determining what they are.
Is there a routine which would suspend the in and out buffers of a command prompt or any other process? There must be some way to make this behave more like a normal shell.
Thanks!
|
|
|
|
|
Maybe you can try replacing _exec with system, provided you have access to all portions of the source code where the change should be made.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
hi,
i've created a template for the open file dialog box to display a opengl scene. in the WM_INITDIALOG message, i create a thread which initialize the opengl env. my problem is that i don't see anything displayed while everything is ok (i'm doing a lot of checks).... is there something preventing the common dialog boxes to support threads ??
if you have a solution that works without thread, i would like to hear it 
thanks for your help.
note : i don't use mfc.
haust
|
|
|
|
|
It is unlikely that open file dialog box should even notice that one of its controls leaves in another thread. It is my understanding that you have a window in another thread where opengl draws something, is that correct? Opengl on another hand, as understand, needed to be initialized per thread.
|
|
|
|
|
hi Alex0,
actually it works the problem was that, since the code i used was a quick cut-and-paste from another standalone modeless dialog source, i forgot that when the dialog was created it was immediately hidden and the thread was suspended.
now, if the open dialog was still visible (i guess there is some piece of code rejecting the hide order) the thread routine responsible for opengl management was actually suspended hence no scene display. i've removed the problematic lines and all is fine now
|
|
|
|
|
Hello,
I have an App. based on a CFormView, when I size my App. and than open a random file, the app. is sized back to its initial size. Any ideas to keep it from sizing back? This behaviour seems to be by design because I created a new project with the Classwizzard and didn't add any code and it still sizes back to its initial state!
Thanks,
Arjan.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
