C / C++ / MFC

3-Jan-03 4:37

I am developing a MFC SDI Application connecting to a SQL Server database through ADO.
The problem in hand is that if multiple users are connected to the database and if one user makes any change in database, a message describing the change need to be propogated to all other connected users. It will depend upon user if he want to load this change or not.

Any ideas on how to do this? If you guys could provide me some sample code that would be great

Resize Metafile

Anthony98873-Jan-03 4:14

Anthony9887

3-Jan-03 4:14

I'm having difficulty resizing a Metafile. I tried using StretchBlt without any luck. Any ideas,

Thanks

Re: Resize Metafile

Gary R. Wheeler3-Jan-03 5:26

Gary R. Wheeler

3-Jan-03 5:26

Metafiles are lists of GDI primitives. They should 'draw to fit' without any difficulty. StretchBlt is used to stretch/draw one bitmap onto another, and doesn't work with metafiles. Could you post your drawing code for the metafile?

Software Zen: delete this;

Re: Resize Metafile

Roger Allen3-Jan-03 5:39

Roger Allen

3-Jan-03 5:39

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?

bool and BOOL

monrobot133-Jan-03 4:10

monrobot13

3-Jan-03 4:10

Quick question: what is the major difference between bool and BOOL and when should I use one or the other?

- monrobot13

Anonymous3-Jan-03 4:22

3-Jan-03 4:22

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)

nde_plume3-Jan-03 5:41

nde_plume

3-Jan-03 5:41

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];

DaveZ3-Jan-03 7:07

DaveZ

3-Jan-03 7:07

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.

Completion Ports and ODBC

stanley guan5-Jan-03 14:58

stanley guan

5-Jan-03 14:58

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

Dave-B3-Jan-03 3:37

Dave-B

3-Jan-03 3:37

Im dipping my toe into the murky waters of i/o completion ports. Confused | :confused:

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

Re: Completion Ports and ODBC

NormDroid3-Jan-03 3:46

NormDroid

3-Jan-03 3:46

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.

Re: Completion Ports and ODBC

Dave-B3-Jan-03 4:02

Dave-B

3-Jan-03 4:02

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 Dead | X|

. 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

Re: Completion Ports and ODBC

Anders Molin3-Jan-03 13:55

Anders Molin

3-Jan-03 13:55

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 Wink | ;)

- Anders

Money talks, but all mine ever says is "Goodbye!"

Do I have a resource leak?

georgiek503-Jan-03 2:36

georgiek50

3-Jan-03 2:36

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) ?

Joaquín M López Muñoz3-Jan-03 2:49

3-Jan-03 2:49

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

georgiek503-Jan-03 6:34

georgiek50

3-Jan-03 6:34

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.

Joaquín M López Muñoz3-Jan-03 7:33

3-Jan-03 7:33

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

_execv from one console app to another

georgiek503-Jan-03 10:48

georgiek50

3-Jan-03 10:48

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?

Anonymous3-Jan-03 2:20

3-Jan-03 2:20

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!!!

Anders Molin3-Jan-03 2:33

Anders Molin

3-Jan-03 2:33

Just an idea...

Try CreateProcess instead of _execv

- Anders

Money talks, but all mine ever says is "Goodbye!"

Anonymous3-Jan-03 2:37

3-Jan-03 2:37

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!

Joaquín M López Muñoz3-Jan-03 3:03

3-Jan-03 3:03

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

Anonymous3-Jan-03 3:14

3-Jan-03 3:14

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!

Joaquín M López Muñoz3-Jan-03 5:06