C / C++ / MFC

Richard Andrew x6420-Sep-24 10:07

Richard Andrew x64

20-Sep-24 10:07

Is it possible that you're performing a lengthy operation on the user interface thread, and that's why it's freezing?

From the "code" that you posted, it looks like that's exactly what you're doing.

If you do anything non-trivial when the button is clicked, then you should assign the task to a worker thread so that the UI thread is free to process UI inputs.

The difficult we do right away...
...the impossible takes slightly longer.

jeron120-Sep-24 10:47

jeron1

20-Sep-24 10:47

Oddly, they post different 'code' in QA.
GUI freezes randomly /MFC/C++[^]

"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment
"Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst
"I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle

Zishan Ud78720-Sep-24 23:11

Zishan Ud787

20-Sep-24 23:11

Hi @jeron1 , Thanks for pointing it out. Updated the question there as well .

Zishan Ud78720-Sep-24 23:16

Zishan Ud787

20-Sep-24 23:16

Thanks for the reply. It's not a lenghty operation (Hardly takes 1 sec) Also,I am doing that only assigning the task to a worker thread. I have updated the code flow in the question , It will give you the exact idea about how am i doing it.

Dave Kreskowiak20-Sep-24 13:53

Dave Kreskowiak

20-Sep-24 13:53

You're lucky it works at all. The sample code you posted posts messages to disable the controls, but those message should never get processes because the UI thread is still busy with "Do some logical processing," so it never processes those messages to disable the controls.

The processing of the messages will stay queued up until the UI thread is done with your "Do some logical processing" and returns after posting the messages to re-enable the controls. Once the UI thread is back in the "idle state", meaning your back in the message pump code picking up messages and dispatching them, only then will the messages you posted get processed. So that's where your app is "freezing".

Like Richard said, if you've got long-running processing going on, move that processing to a task or background thread. You'll also have to rewrite your code to wait for the task to complete before posting the messages to re-enable the controls.

The goal is to keep the UI thread available and running in the message pump for as much as possible.

Asking questions is a skill
CodeProject Forum Guidelines
Google: C# How to debug code
Seriously, go read these articles.
Dave Kreskowiak

David Crow23-Sep-24 2:05

David Crow

23-Sep-24 2:05

Zishan Ud787 wrote:
case BUTTON1:

This case is not ever going to execute because it's all uppercase (and what's getting assigned to m_threadCmd is not). Is that intentional?

"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

Character set

Calin Negru12-Sep-24 23:03

Calin Negru

12-Sep-24 23:03

Unicode is 1byte per character, that’s the Latin characters and the other symbols found on a standard keyboard
Multibyte is Latin, Greek, Russian and everything else that exceeds the initial 256 symbols
Is that how it works?

CPallini12-Sep-24 23:19

CPallini

12-Sep-24 23:19

Quote:
Unicode is 1byte per character

Nope. See, for instance: Unicode - Wikipedia[^].

There are single byte character sets, like, for example ISO/IEC 8859-1 - Wikipedia[^] or Windows-1252 - Wikipedia[^].

"In testa che avete, Signor di Ceprano?"
-- Rigoletto

Calin Negru12-Sep-24 23:46

Calin Negru

12-Sep-24 23:46

I thought a c++ char has the size of one byte. How can something that is greater that 1 byte (Unicode, Multibyte) fit into a char?

Mircea Neacsu13-Sep-24 0:06

13-Sep-24 0:06

It cannot; it is using an “encoding”, the most popular by far being UTF-8[^].

Mircea

trønderen13-Sep-24 9:33

13-Sep-24 9:33

Mircea Neacsu wrote:
the most popular by far being UTF-8[^].

I'd say that the most popular file storage format is UTF-8.

As a working format, in RAM, UTF-16 is very common. E.g. it is the format used by all Windows APIs, which is more or less to say all Windows programs. Java uses UTF-16 in RAM, as do a lot of other modern languages.

It must be said that not all software that claims to use UTF-16 fully handles UTF-16 - only the BMP ("Basic Multilingual Plane"), so that all supported characters will fit in one 16-bit code unit. BMP didn't have space for latecomer alphabets, like for a number of African or Asian languages. Most developers said "But my program isn't aimed at such markets, so I'll ignore the UTF-16 surrogates, for handling such characters as two 16-bit code units. I can treat text as if all characters are of equal width, 16 bits".

But a new situation has arisen: Emojis have procreated to a number far exceeding the number of WinDings. They do not all fit in BMP, so a number of them have been allocated in other planes than BMP. Don't expect the end user to know which emojis are defined in which planes and refrain from using non-BMP emojis! If you are not prepared for them, your code may mess up the text badly.

Writing your own complete UTF-16 interpreter is not recommended. Use library functions! There is more to UTF-16 than just alternative planes: Some character codes are nonspacing, or combining (typically an accent and a character). So you cannot deduce the number of print positions from the length of the UTF-16 string - not even after considering control characters.

For "trivial" strings limited to Western alphabets, there usually is a fairly close correspondence between the number of UTF-16 code units and the number of positions. You can pretend that it is exact, but look out for cases that need to be treated as exceptions. I suspect that is what a lot of programmers do. 99,9% of Western text is free of exceptional cases, so the fixed-code-width assumption holds. Until, of course, emojis become common e.g. in file names. Note that UTF-32 does not provide an ultimate solution to all problems: You still may have to relate to nonspacing or combining characters!

Religious freedom is the freedom to say that two plus two make five.

Mircea Neacsu13-Sep-24 17:17

13-Sep-24 17:17

I have to confess that I am a convert to the UTF-8 religion as preached in the UTF-8 Everywhere[^] manifesto. So much so that I've written a series of articles[^] on CP about using UTF-8 in Windows (you can find the whole series here[^]).

Some of your assertions are open to interpretations:

Quote:
So you cannot deduce the number of print positions from the length of the UTF-16 string - not even after considering control characters.

Why would that be interesting from a programming point of view? From a typographical point of view, sure, but as programmers we don't usually concern ourselves with such minutia Smile | :)

The subject of emojis is another pet peeve of mine so allow me a bit of a roundabout. Some evolutionary solutions have been reinvented many times: flight has been reinvented by insects, birds, mammals, you name it. However there are some crucial points in evolution that happened only once. Photosynthesis or eukaryotic cells are prime examples but so is alphabetic writing. Moving from pictographic writing, where a symbol represented a whole word, to one where a symbol represented a sound, was a magnificent achievement of the human spirit that opened the path to what we now call the Western civilization. Now, if you buy at least some of my arguments, you can see how disappointed I am when this whole evolutionary path is turned back by the spread of emojis. No longer we need the magic words of a Shakespearean sonnet when we can just put a heart and a smiley face. Bleah!

Mircea

trønderen14-Sep-24 7:25

14-Sep-24 7:25

Mircea Neacsu wrote:
Quote:So you cannot deduce the number of print positions from the length of the UTF-16 string - not even after considering control characters.
Why would that be interesting from a programming point of view?

If you code anything that is to be presented to a user, you will frequently have to relate to the physical space available, whether a 16 char single line display on an embedded device, or a field in a form on a desktop PC.

If you just send it the entire string, leaving to the display unit to discard what won't fit, for one: You may upset the display device. Second: Maybe it is obvious to you that the first 'n' characters are displayed, but don't trust it: Many small-display devices display a rolling text, so the last 'n' characters are displayed. In either case, your customer may be less than satisfied with your solution. If you present floating point values with the number of decimal positions less than the internal precision (which is almost always the case), you may want to consider rounding the last displayed digit - don't expect a pure UI module to have any concept of floating point rounding! (Besides, it may want the values as separate digits, not as an FP value.)

Even if a value is not presented to a human user, it may be exchanged with another software module in textual format. The receiver may provide a limited size text buffer, or may require a minimum number of (valid) characters (possibly converted to 7-bit ASCII with zero parity, if it is an old *nix application!)

If your software has nothing at all to do with a user interface, you may still be handling data that you handle over to some software doing the UI. This software may put restrictions on the lengths of both prompt strings and data values. You may have to make decisions about what to display, either by some form of abbreviation (Initial only, ellipsis, ...), leaving (semi-)optional parts out, etc.

I certainly can think of specific programming tasks that are completely unrelated to character string length. But to me, those are special cases. The main rule is that the printable length, both in number of positions and the typographical length (when using variable width fonts) can be essential, and you should be prepared to handle it. You ask a Unicode handling library function for the number of positions when you need it. You ask a UI typography library function for the typographical length if that is what you need e.g. to shorten the string to fit into a field.

Religious freedom is the freedom to say that two plus two make five.

Mircea Neacsu14-Sep-24 15:10

14-Sep-24 15:10

My remark was made mostly tongue-in-cheek (hence the smiley after it). Of course the length of the rendered text is of interest in many/most applications. It's just that, luckily, I don't have to worry about it because people who write the nitty-gritty of UI have taken care of it. For instance, in Windows, I can just call GetTextExtentPoint32[^] function to have the text measured.

However this has noting to do with UTF-8 vs UTF-16. I remain of the opinion that UTF-16 has no particular advantage when compared with UTF-8. (If there are other readers of this conversation, please don't start a flame war now - this is just a personal opinion). I see UTF-16 as a stepping stone when computing world needed to move away from ASCII, but in this day and age, it has served its purpose and we can move away to something better.

Mircea

trønderen14-Sep-24 17:27

14-Sep-24 17:27

Mircea Neacsu wrote:
However this has noting to do with UTF-8 vs UTF-16

That is certainly true.

Mircea Neacsu wrote:
I remain of the opinion that UTF-16 has no particular advantage when compared with UTF-8.

I am leaning towards agreeing with you.

Mostly, I am observing - and has been observing for 40+ years - that people strive for non-Einstein solutions, "Make it as simple as possible, but no simpler". People want to do it simpler! For years, I heard lots of people say that 32 bits is overkill, Unicode will never grow beyond the first plane, BMP - there isn't anywhere close to 65,536 different characters! And for a number of years, they were right: Unicode did manage with the basic plane only.

That is when people started using 16 bit characters, although I am not sure that the name UTF-16 was know that early. With BMP only, most simple(r than possible) developers thought it quite simple; a string of 16-bit characters was just like a string of 8-bit characters, only with more characters. (Look at the History section of Wikipedia: Unicode[^] - even the initial developers of Unicode argued the same!)

If it had ended up that way, it would have been significantly simpler: You can count the number of characters as easily in 16 bit as in 8 bit character code. You can index character 23 by string8[23] or string16[23]. In other words: I can fully understand why Windows NT (1993) and Java (1995) went for 16 bit characters. (At the time of Windows NT release, UTF-8 had been proposed, but was not yet accepted as a standard - anyway, you don't change the system character encoding from 16 bits fixed to n*8 bits a few weeks before the release of a new OS!)

As we all know now, the solution was simpler than possible. Several of my coworkers were highly surprised when BMP overflowed, but didn't worry: We are never going to encounter those characters in the entire lifetime of our software! I think that they for at least ten more years continued to access character 23 by string16[23]. I can understand them. Until we got emojis in other planes, they were essentially right.

But it was a too simple solution. When you were forced to handle multiple planes, and maybe you at the same time discovered combining and non-spacing codes, then the simplicity disappeared. You have all the same issues with UTF-8; it is not any worse with UTF-16, and in Western text, the special cases occur rarely. Most of the time, UTF-16 is more straightforward, but you have to be prepared for the exceptions. With UTF-8, you can never relax; you handle variable length characters all the time! (At least if you regularly write non-English text, which is the common case in most European countries.)

If UTF-8 didn't exist, I would be happy with sending UTF-16 memory strings straight to file. Having UTF-8 as an alternative in-memory format creates trouble; I want one single unambiguous string format. Now that Windows, Java and C# both use UTF-16, I am not going to start using UTF-8 in-memory.

But I also want to have one singe unambiguous file format. UTF-8 is established, UTF-16 is not. So UTF-8 wins. I am stressing: Don't waste your time trying to process UTF-xxx yourself; use library functions. So when I read text from or write text to file, I let library functions process the strings. Each format has its use.

After all, I guess I really disagree with you: If we start with a tabula rasa, but we are to select The One And Only Encoding, UTF-16 and UTF-8 are equally good. But that isn't the situation in memory: Windows and numerous other essential tools/subsystems have based themselves on UTF-16. Given that, using UTF-8 in my application strings would introduce a lot of complexities. So accepting the realities of life, my programs will continue to use UTF-16 strings.

Until, of course, I start working with an OS having UTF-8 as its system string encoding and languages/tools that use UTF-8 as their in-memory string encoding.

Religious freedom is the freedom to say that two plus two make five.

Mircea Neacsu15-Sep-24 2:26

15-Sep-24 2:26

trønderen wrote:
After all, I guess I really disagree with you

World would be too boring if we wouldn't have different opinions Laugh | :laugh:

trønderen wrote:
I want one single unambiguous string format.

You aren't going to get it, or at least not in this lifetime Smile | :)

. If you go to Linux or Mac worlds, everything is UTF-8. In Windows world it's UTF-16 with a sprinkle of UTF-8.

trønderen wrote:
But I also want to have one singe unambiguous file format. UTF-8 is established, UTF-16 is not. So UTF-8 wins.

If I understand you correctly, you suggest having UTF-8 files converted to UTF-16 on entry, processed as UTF-16 inside the application and converted back to UTF-8 on output. That would complicate things very much if you target different OS-es. It would also be inefficient if your app doesn't require the UTF-16 parts of the OS (ReadFile and WriteFile functions in Windows work with any encoding).

My strategy is almost a mirror image of that: Everything is UTF-8 until it needs to call certain OS functions when a thin wrapper converts all inputs to UTF-16 and all results back to UTF-8.

Mircea

trønderen15-Sep-24 12:16

15-Sep-24 12:16

Mircea Neacsu wrote:
If I understand you correctly, you suggest having UTF-8 files converted to UTF-16 on entry, processed as UTF-16 inside the application and converted back to UTF-8 on output.

A simple UTF-8/16 conversion filter (included by default) in the StreamReader/Writer, or whatever your IO classes are named certainly does not complicate things for the developer.

For interaction with other systems, whether they use UTF-8, UTF-32 or UTF-16 as a working format, UTF-8 is the lingua franca, the Esperanto of textual information. It is The File Character Encoding. No application needs to be concerned about it.

That would complicate things very much if you target different OS-es.

If your alternative is to reject any OS that does not use UTF-8 as its system character encoding, and all programming languages, libraries and development environments that does not use UTF-8, you are most certainly right. In that situation, I would certainly go for UTF-8 in-memory as well.

For a great number of developers, in-memory UTF-8 isn't a viable option. UTF-16-oriented OSes, languages and tools are a fact of life. I say; When in Rome, roam with the Romans (or however they saying goes). Even though a lot of developers of drivers and interrupt handlers and low-level network protocols with only rudimentary textual output work in *nix-like environments, the great majority of those communicating textually, with users and others, roam Rome in UTF-16 environments.

If you are talking about making applications that can be ported between UTF-16 and UTF-8 oriented OSes without a single source code change in the string handling, and your code assuming UTF-8 strings even under an APIs expecting UTF-16, then you are overly optimistic. You will have to do a lot of adaptations to UTF-16-oriented library and system functions. Or wrap every single one of them in a two-way-conversion wrapper.

The best way to handle it is to leave all string handling to library functions, you application knowing nothing about the encoding under the hood. (Your floating point application would probably run fine on a machine with an FP format different from IEEE-754!). Treat a string as a string, regardless of encoding. Make sure that when you handle characters individually, you use a char32 to hold them.

If you go to Linux or Mac worlds, everything is UTF-8.

Most certainly not. Well, I never worked with Mac, but in Linux there are loads of software that can't handle anything but 8 bit character sets. You can even come across those that cannot handle 8 bit, but only 7 bit characters. A few years ago, I was editing a configuration file on a Unix system; that network module crashed immediately because I had added a comment which contained a non-ASCII 8859 character (in the name of one maintainer).

A number of RFC-822 based internet protocols still cannot handle ISO 8859 (it would be against RFC-822). There still is a real need for QP encoding, backslash or ampersand encoding, etc.

You may rightfully say that *nix/Mac apps written to handle UTF-8 does handle UTF-8. Big surprise. You may claim that languages/tools specifying UTF-16 string representation doesn't use that when running under *nix/Mac - all strings are converted to UTF-8 when ported to these OSes, both in source code and library APIs. I doubt very much that that is the case.

Religious freedom is the freedom to say that two plus two make five.