C / C++ / MFC

Jochen Arndt9-Mar-16 22:38

Jochen Arndt

9-Mar-16 22:38

WM_USER is obsolete. Use WM_APP instead. Or better use registered messages.

A good description about this topic can be found in the CodeProject article Message Management[^].

Richard MacCutchan9-Mar-16 23:17

9-Mar-16 23:17

WM_USER+x should only ever be used inside a single application, as it is free to use by everyone. Using it in a driver is almost bound to cause tears before bedtime.

[edit]
WM_USER (Windows)[^] and WM_APP (Windows)[^] list the rules.
[/edit]

Bram van Kampen10-Mar-16 15:03

10-Mar-16 15:03

Thanks,

I am aware of RegisterMessage(...) etc, but have always considered it as a canon to shoot a fly. It may be the better Idea for future, particularly after the nightmare I encounter now. Your idea of attaching a GUID is particularly fetching.
WM_USER +X, It worked for me many a time in the past. I can now see the flaws

Thanks,

Bram. Smile | :)

Bram van Kampen

Richard MacCutchan10-Mar-16 22:15

10-Mar-16 22:15

Jochen Arndt10-Mar-16 22:38

Jochen Arndt

10-Mar-16 22:38

It looks like a reply to my answer posted to yours inadvertently.

Richard MacCutchan10-Mar-16 22:50

10-Mar-16 22:50

I don't know what Bram is smoking these days, but I think he should cut down. Wink | ;)

Bram van Kampen10-Mar-16 15:08

10-Mar-16 15:08

Hi,

Good to talk again.

My header files do not provide a macro for WM_APP. Maybe you could let me know for future reference, if it is a single value. Also AOP has advised me to Register a Windows Message. Probably the way forward for the Future.

Thanks for your contribution.

Bram. Smile | :)

Bram van Kampen

Ensuring code runs synchronously

Victor Nijegorodov11-Mar-16 4:17

Victor Nijegorodov

11-Mar-16 4:17

WM_APP (Windows)[^]

ForNow9-Mar-16 5:01

Re: Ensuring code runs synchronously

9-Mar-16 5:01

Is a crtical section a way of ensuring the your code runs synchrounsly as window message processing seems to take precedence in code execution

Richard MacCutchan9-Mar-16 7:21

Re: Ensuring code runs synchronously

9-Mar-16 7:21

It ensures only one thread can go through that code path: see Critical Section Objects (Windows)[^].

ForNow wrote:
window message processing seems to take precedence

Not sure what you mean by that.

Bram van Kampen9-Mar-16 15:29

Re: Ensuring code runs synchronously

9-Mar-16 15:29

In Short, No!

Critical Sections are Synchronisation Objects, It is of use only if your project is multi threaded,ie Has More than One thread running in the One Program. Each thread of your program, will wait in front of a CriticalSection where you try to Enter It, until all other threads leave it. It is a communal comunication deal between threads in a program. One thread of a program will not allow another thread to run, until the section is released. Other programs can switch thread in the mean time.

The Nature and context of the question worries me! You seem to have to learn an awfull lot more before you are ready to discus critical sections

Smile | :)

Bram van Kampen

Bram van Kampen9-Mar-16 16:04

Non display characters for selection count

9-Mar-16 16:04

No,
It is NOT, and I explained that already!
However, I also answered your other question, in quite a lot of detail. Before you can attempt to learn MFC Multi Threaded Programming, you will need to learn basic MFC Programming, and elements of the Windows SDK. MFC is a thin wrapper around the Windows SDK. Sometimes you need the real thing! Definitely needed in Multithreading.

Cannot Help it, You need to study more before we can help you.

Bram

Bram van Kampen

ForNow8-Mar-16 20:44

8-Mar-16 20:44

Hi

I have 3 rows of text in my rich edit.
At the end of each line I move a carriage return line feed, to force a new line
/r/n. Do these 2 bytes count as 2 characters when determining the count for the selection

Thanks

Richard MacCutchan8-Mar-16 22:45

8-Mar-16 22:45

The documentation at EM_GETSELTEXT message (Windows)[^] does not explicitly say whether it does, or does not. But a simple test should prove it one way or another.

ForNow9-Mar-16 4:55

9-Mar-16 4:55

cr/lf 0X0D0A is treated as 1 character for rich edit purposes

thanks

David Crow9-Mar-16 5:24

9-Mar-16 5:24

Really? I just tested (using VS2008) and it came out as two separate characters. Here's the code I used:

// the control contained the text: David\r\n

void CMyDialog::OnClickedOk()
{
    int len = m_richedit.GetWindowTextLength();
    TRACE(_T("Len = %d\n"), len);

    CString text;
    m_richedit.GetWindowText(text);
    TRACE(_T("Text = %s\n"), text);

    for (int x = 0; x < len; x++)
        TRACE(_T("%#x\n"), text[x]);
}

The resulting output looked like:

Len = 7
Text = David

0x44
0x61
0x76
0x69
0x64
0xd
0xa

"One man's wage rise is another man's price increase." - Harold Wilson

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles

ForNow9-Mar-16 5:32

9-Mar-16 5:32

I was referring to richedit when determining the selection position

David Crow9-Mar-16 5:49

9-Mar-16 5:49

So you are taking whatever text is already present in the edit control and adding CRLF to the end of it? I'm trying to ascertain if this is an appending issue (I've seen some weird ways in which folks try to append to an edit control) or something else.

modified 9-Mar-16 11:41am.

ForNow9-Mar-16 5:58

9-Mar-16 5:58

For Crlf which is 2 bytes in memory aka the buffer
I count 1 for determining the selection count

David Crow9-Mar-16 6:03

9-Mar-16 6:03

But are taking whatever text is already present in the edit control and adding CRLF to the end of it?

ForNow9-Mar-16 6:20

9-Mar-16 6:20

The text is included in the count for the cold I count as 1 character for porpouses of selection not 2 bytes

David Crow9-Mar-16 6:40

9-Mar-16 6:40

I misunderstood what you were attempting.

You are using the GetSel() method to get the starting and ending positions of the control's selected text, correct? I tried that and with all of the text in the control selected, I found that CR and LF are (like I would expect) considered two separate characters. In other words, start = 0 and end = 7.

ForNow9-Mar-16 6:45

9-Mar-16 6:45

I use the Streamout api to get whatever is in the control the edit control has 4 lines at the end of each line is X0D0A CRLF I have to count the 0X0D0A as 1 character for the SetSel api when determining the pos I want to use in the selection

thanks

David Crow9-Mar-16 6:53