|
i am doing something like--->
BOOL CHTSL_ScintillaCtrl::OnNotify(WPARAM wParam, LPARAM lParam, LRESULT* pResult)
{
char ch;
SCNotification *scn_notify; //stores notification message...
switch (scn_notify->nmhdr.code)//The event which happened.
{
case SCN_CHARADDED: //if a new character is added.
//Some code which extracts the currently typed character. Working fine..
//value stored in ch.
if(ch==0x0A || ch==0x0D)
{
///Some operations
}
The above if condition is not working for Enter key. All other characters i am able to identify. Is there any other value assigned to NewLine?
|
|
|
|
|
I believe you need to set up a text box to accept the enter key, it generally doesn't.
Christian Graus - C++ MVP
'Why don't we jump on a fad that hasn't already been widely discredited ?' - Dilbert
|
|
|
|
|
I am developing an editor using Scintilla. If i am doing the same thing in VB, by comparing the character with vbCr, it is working fine. Another thing...
If i am doing, (ch== -52), it is detecting the Enter key with that code..I dont understand the logic.
|
|
|
|
|
You can do something like:
BOOL CYourCtrl::PreTranslateMessage(MSG* pMsg)
{
switch (pMsg->message)
{
case WM_KEYDOWN:
switch (pMsg->wParam)
{
case VK_RETURN:
Somethings seem HARD to do, until we know how to do them.
 _AnShUmAn_
|
|
|
|
|
cast all values to int and use ( (ch==0x0A) || (ch==0x0D) ) ..it sometimes helps.
Greetings from Germany
|
|
|
|
|
vikram.vit wrote: if(ch==0x0A || ch==0x0D)
Have you put a breakpoint on this line to check the value of ch when the Enter key is pressed? Knowing why the condition is failing will go a long way towards solving the problem.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Hi All,
I am working with CFileFind MFC. Here I have a dialog based application that shows list of files in a directory.
I need to show the staus information on the STATIC control of that dialog while processing.
How do i this? Is threading concept useful? if yes can you show me some links about it.
Thanks.
|
|
|
|
|
U should use Thread here.
Come online at:-
jubinc@skype
|
|
|
|
|
Sakthiu wrote: I need to show the staus information...
Of what? The file-find progress, or of the files themselves? Be more specific about what you are after.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Sakthiu wrote: I need to show the staus information on the STATIC control of that dialog while processing.
Do you want that static control should show the current accessed file or directory?
Knock out 't' from can't,
You can if you think you can
|
|
|
|
|
Do you wan to set a progress bar for files 1,2,...1000 ?
|
|
|
|
|
Why WM_ERASEBKGND, since all the paintings can be done with the WM_PAINT itself?
- NS -
|
|
|
|
|
In general the WM_PAINT handler will not "touch" every pixel: it might just write some text in the corner for example. Still the entire client area need to be updated if its dirty. Thus the two stage painting.
Steve
|
|
|
|
|
OK... that i know.
But my doubt is, since WM_PAINT will update enough area in the window, is WM_ERASEBKGND necessary? And i could find out that if a WM_ERASEBKGND message is sent, WM_PAINT will be surely sent after that to update the whole area. So i think there is no need to process WM_ERASEBKGND to draw anything.
- NS -
|
|
|
|
|
NS17 wrote: But my doubt is, since WM_PAINT will update enough area in the window, is WM_ERASEBKGND necessary
It depends. If your WM_PAINT handler paints every dirty pixel then you don't need WM_ERASEBKGND. If, as is generally the case, the WM_PAINT handler only touches a subset of the dirty pixels then without the WM_ERASEBKGND handler the dirty pixels not painted will still be dirty. It depends on your application.
You can handle the WM_ERASEBKGND message and return 0 to stop the erasing if you want to.
Steve
|
|
|
|
|
Stephen Hewitt wrote: as is generally the case, the WM_PAINT handler only touches a subset of the dirty pixels then without the WM_ERASEBKGND handler the dirty pixels not painted will still be dirty
Could you please explain a little more?
- NS -
|
|
|
|
|
The WM_PAINT does not always paint the whole of the DC, it is passed an 'update region' which is a series of 'dirty' rectangles. Lets say you drag a button around on your window. The rectangle for the new position is passed to WM_PAINT, without the WM_ERASEBKGND The rectangle of the old position would not be filled in, causing a trail effect. The button will only paint within it's own bounds ( the first rectangle ) since it knows nothing of lies beneath it.
In most cases WM_ERASEBKGND is not required, but if there is anythig on your main window that changes appearance ( uncovering pixels beneath it ) then this message will fill in those pixels giving WM_PAINT a fresh canvas.
There are a few class styles that also effect the painting of a window, CS_VREDRAW, CS_HREDRAW, CS_CLIPCHILDREN, CS_CLIPSIBLINGS to name a few...
|
|
|
|
|
WalderMort wrote: The rectangle for the new position is passed to WM_PAINT, without the WM_ERASEBKGND
...but from Spy++ tool I found that WM_ERASEBKGND is also coming while dragging a message box over a window (I used notepad).
- NS -
|
|
|
|
|
Just like with my example using your window and a button, the desktop is itself a window, when you move a window over yours, those pixels are erased, the desktop is telling your window that it is now uncovered and should fill in those uncovered areas.
|
|
|
|
|
Can anyone show a condition when WM_PAINT is sent but WM_ERASEBKGND is not? or when WM_ERASEBKGND is sent but WM_PAINT is not?
|
|
|
|
|
If you use InvalidateRect(...,..., false) then only WM_PAINT is sent. If you use InvalidateRect(...,..., true) then WM_PAINT is called and when you use 'BeginPaint' inside WM_PAINT it calls WM_ERASEBKGND (when WM_ERASEBKGND is called, the Invalid rectangle is nullified).
In a normal circumstance the Invalidate rectangles received in WM_ERASEBKGND and WM_PAINT are same.
|
|
|
|
|
Hi
I think this is depend on how the window be update. When you call Invalidate(...), you can specify the erase background occuer or no. I think when you want to update only an item in the window like a button in the toolbar NOT all window area, WM_ERASEBKGND is not needed because not change made in other places of the window.
Kind Regards. mrjavadtaheri@gmail.com
|
|
|
|
|
Whether it is background or foreground you draw on same DC. This is only an option given to you to separate background and foreground. The usefulness comes when 'InvalidateRect' etc. are called in the program. Normally, WM_ERASEBKGND and WM_PAINT both get called ('resize' say). If you use InvalidateRect(...,...,false) only WM_PAINT gets called. If you use InvalidateRect(...,...,true) then WM_ERASEBKGND gets called when you use 'BeginPaint' inside WM_PAINT.
|
|
|
|
|
Thanks! But why a reply now, after years? (just due to curiosity)  - ns ami -
|
|
|
|
|
Hello everybody!
Is there any way to start an application at bootup!
for eg:
a program to display the date of the day when the user has logged in!
If you happen to know the concept,I humbly request you to kindly respond me!
Thanks in advance!
Shalini
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
