C / C++ / MFC

Re: Don't get WM_COPY in my class?

15-Feb-02 10:36

I would like to generate those standard "accelerators" dynamically...

I see. Well, then maybe accelerators are not the best solution. Another solution that does not require the user of your class to do any extra work is: handle WM_KEYDOWN, check for the CTRL+C code and send the WM_COPY command when appropriate.
As for the code for CTRL-C, I don't know it right off the top of my hat, but you can just write some OutputDebugString or something in your OnKeyDown to find it out.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

16-Feb-02 6:24

yep, it works. Big Grin | :-D

BOOL CListBoxChat::PreTranslateMessage(MSG* pMsg) 
{
	if(pMsg->message == WM_KEYDOWN)
	{
		TRACE("[LBC] DEBUG WM_KEYDOWN %d\n", pMsg->wParam);

		switch(pMsg->wParam)
		{
		case 'C': 
		case VK_INSERT:
			if(GetKeyState(VK_CONTROL)) 
			   return SendMessage(WM_COPY);
			break;
		}
	}
	return CListBox::PreTranslateMessage(pMsg);
}

Re: Don't get WM_COPY in my class?

Joaquín M López Muñoz16-Feb-02 6:28

Using a Timer in a Subclassed Control

16-Feb-02 6:28

Congratulations! Good luck with your project.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

MJ_Karas15-Feb-02 9:24

MJ_Karas

15-Feb-02 9:24

I have a question of about the use of a system timer within a class. The class
in question is a dialog control class derived from CEdit. What I need to know
is when is the appropriate time to allocate and setup the timer via the call
to SetTimer(). I also need to know when is the appropriate time when to quit the
timer service via the call to KillTimer(). My initial thought was as follows:
Call SetTimer() within my class constructor;
Call KillTimer() within my class destructor;
However I have been thinking if it would be better to add event routines to my
class to support the WM_CREATE and WM_DESTROY and place the calls as follows:
Call SetTimer() within my class OnCreate() event handler;
Call KillTimer() within my class OnDestroy() event handler;
For any of you out there that are more experienced than myself I would ask....
Which of these approaches is better or more apt to work better? And if these
are neither appropriate then what is the proper implementation?
Thank you,
Mike

Joaquín M López Muñoz15-Feb-02 9:37

15-Feb-02 9:37

Call SetTimer in CYourEdit::OnCreate. Kill the timer in CYourEdit::OnDestroy (or alternatively, let the timer be killed by the system upon window destruction).

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

Nemanja Trifunovic15-Feb-02 9:47

Nemanja Trifunovic

15-Feb-02 9:47

... and before all that, read this article about timers Smile | :)

I vote pro drink Beer | [beer]

MJ_Karas15-Feb-02 11:14

MJ_Karas

15-Feb-02 11:14

Thankyou All that replied on the Timer issue. And thx esp to Nemanja for the link to the timers article.
Mike
Wink | ;)

Mazdak15-Feb-02 9:47

Is it possible to have JScript Vars from VC

15-Feb-02 9:47

WM_CREATRE and WM_DESTROY are good place

Mazy

Don't Marry a Person You Can Live With...
Marry Someone You Can Not Live Without

15-Feb-02 8:57

I'm stuck. I have MFC-based application, which has in itself CHtmlView. I'd like to have var list in JScript in the current page.

Or maybe somebody know the way to write own JScript debuger?

Thnx in advance,
Sergey

DLL Register Server

Nnamdi Onyeyiri15-Feb-02 7:51

Nnamdi Onyeyiri

15-Feb-02 7:51

I am making a regular DLL, and want it to be situated in the windows folder, so each program i make that is installed does not need a seperate copy, but do not know how to do that.

Can someone help?

==================================================
When Your Mind Wonders...Where Does It Go???

Joaquín M López Muñoz15-Feb-02 7:51

15-Feb-02 7:51

If you're using some installation progfam to do your install package, then there will be means there to indicate that a certain DLL must be located in the system folder.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

Nnamdi Onyeyiri15-Feb-02 7:58

Nnamdi Onyeyiri

15-Feb-02 7:58

I seem to remember looking at some code tht had a function to do with registering, so i thought you needed to add some code into the DLL.

==================================================
When Your Mind Wonders...Where Does It Go???

Mazdak15-Feb-02 8:03

15-Feb-02 8:03

If you use ATL wizard to write dll,it add those function for you,you only add dll to installshield and check it as selfregister in installshield wizard and installshield do another things for you

Mazy

Don't Marry a Person You Can Live With...
Marry Someone You Can Not Live Without

Mazdak15-Feb-02 7:58

15-Feb-02 7:58

run this on command:
regsvr32 pathoffile

also if you compile your dll project it is self register and it will register automaticlly

Mazy

Don't Marry a Person You Can Live With...
Marry Someone You Can Not Live Without

Nemanja Trifunovic15-Feb-02 8:04

Nemanja Trifunovic

15-Feb-02 8:04

Maybe this term 'regular DLL' confused me, but I don't believe he is developing a COM server. Therefore, he does not need to register anything.

I vote pro drink Beer | [beer]

Nish Nishant15-Feb-02 8:24

Nish Nishant

15-Feb-02 8:24

Yeah

He simply needs to copy it to the system folder within the windows folder

Nish

Nish was here, now Nish has gone;
He left his soul, to turn you on;
Those who knew Nish, knew him well;
Those who didn't, can go to hell.

I like to Jig | [Dance]

on the Code Project

Sonork ID 100.9786 voidmain
www.busterboy.org

Mazdak15-Feb-02 8:42

WM_SIZE & WM_MOVE only sent by DefWindowProc (...) ??

15-Feb-02 8:42

yaep,it seems you're right

Mazy

Don't Marry a Person You Can Live With...
Marry Someone You Can Not Live Without

15-Feb-02 7:20

Hi,
i have a window, simply created with the Win32 API (RegisterWindowEx and CreateWindowEx) no MFC.

I use my own WindowProc (...), and return DefWindowProc to process the messages i don't process myself.... a classic.

I processed the WM_SIZE and WM_MOVE messages up to now without problems, but i have added the processing of the WM_WINDOWPOSCHANGED in my window proc, and i don't receive WM_SIZE and WM_MOVE messages anymore.

Looking at the VC6 docs for WINDOWPOSCHANGED, they briefly say that when DefWindowProc() processes WINDOWPOSCHANGED, it sends the WM_MOVE and WM_SIZE messages to the window.

Then, now i process WINDOWPOSCHANGED myself, that seems to be logic that i don't receive WM_MOVE and WM_SIZE anymore.

Here is my question,
are the WM_MOVE and WM_SIZE messages sent EXCLUSIVELY by DefWindowProc() or does the system(framework) sends these messages to my window too ?

If the system sends them too, could you please tell me when it does so ?

Cheers,
Lion.

Re: WM_SIZE & WM_MOVE only sent by DefWindowProc (...) ??

Joaquín M López Muñoz15-Feb-02 7:41

Re: WM_SIZE & WM_MOVE only sent by DefWindowProc (...) ??

15-Feb-02 7:41

MSDN article Size and Position Messages seems to imply that WM_SIZE and WM_MOVE are only sent from DefWindowProc. Quote:

A window that must process WM_SIZE and WM_MOVE messages must pass WM_WINDOWPOSCHANGED to the DefWindowProc function; otherwise, the system does not send WM_SIZE and WM_MOVE messages to the window.

There could be room for interpretation, but IMHO this paragraph seems to be a little more conclusive with respect to this issue than the documentation on WM_WINDOWPOSCHANGED.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

15-Feb-02 7:51

Thanks,
this is exactly what i needed to know because it isn't explicitly writen in my docs.

Lion.

Re: WM_SIZE & WM_MOVE only sent by DefWindowProc (...) ??

Joaquín M López Muñoz15-Feb-02 7:55

Re: WM_SIZE & WM_MOVE only sent by DefWindowProc (...) ??

15-Feb-02 7:55

You are welcome Smile | :)

Please note that the only information I've got with respect to this issue is the one article I sent to you. So you may want to consider taking precautions before jumping to conclusions. It could be a good idea to have on debug mode some assert(FALSE)s on the processing of WM_SIZE and WM_MOVE, so that if this conclusion proves wrong at least you will know.

Regards,

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo

15-Feb-02 11:45

Well, i placed something in my code that will warn me if i receive one of the two messages but i sincerly doubt about this.
I also found a doc where they specify that a window will not receive any WM_MOVE/SIZE messages if it processes the WM_WINDOWPOSCHANGED and returns 0.

Cheers,
Lion.

problem with mmsystem.h

starn15-Feb-02 7:10

starn

15-Feb-02 7:10

c:\program files\microsoft visual studio\vc98\include\mmsystem.h(113) : error C2146: syntax error :

missing ';' before identifier 'MMVERSION'

c:\program files\microsoft visual studio\vc98\include\mmsystem.h(113) : fatal error C1004: unexpected end of file found

AND HERE ARE THE LINES OF CODES:

/* general data types */

#ifdef _WIN32
typedef UINT MMVERSION;
#else
typedef UINT VERSION
#endif
typedef UINT MMRESULT; #define _MMRESULT_

Does anybody knows what it can be?
Confused | :confused:

Re: problem with mmsystem.h

Joaquín M López Muñoz15-Feb-02 7:13