Is there a reason you need to use multi-line edit controls of a fixed width? It seems like an array of single line edit controls might do what you need and it is easier to limit the length of data in them.
If your current font is a "proportional" one (like Arial, Times New, ...) then it is not possible to calculate the number of characters in a line in a common case.
It will always depend of the text itself. Example:
the text "WWW" needs much more pixels than "111".
But for non-proportional fonts (like Courier New) both need the same number of pixels.
I understand that this is the font statement from resource file dialog definition "FONT 8, "MS Shell Dlg", 400, 0, 0x1" I basically editing for hex characters so my GetTTextExtent string is "0123456789ABCDEF" these characters seem like the size even without a Font like courier new
Have you considered deriving your own class from CEdit, something like:
class MyCustomEdit : public CEdit
Then as each character is typed into the control but before the control is updated, figure out what line the cursor is on (I haven't used MFC in a few years so I'm not sure what these two messages would be). If there is room, let the character through, otherwise not.
"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
probably WM_CHAR and wparam is the keystroke truth that would also save me time on the editing as I can see if it is a valid hex character was entered rather then do GetWindowText to read the entire control
I'm updating my C++ application in to multi thread application in VisualStudio 2013.
In main(), thread's was created by CreateThread()and inside the thread's classA ObjA(); was created & called the function.
In the classA it call another dll method.
Dll was include in to the project through properties->Linker.
Problem was when objA called dll method , application throws access violation reading location.
But without multi-thread it works normal.
Accessing dll method from multi-thread is same way as normal or any other things needed for accessing.
Because the math operations performed by your code result in a NaN?
You cast an integer with at least the relevant most signficant bits set to float or double?
You have a buffer overflow writing such a value to the memory of a float or double?
But I "THINK" even if I do a HeapAlloc for 20 byes it really gets 1K
I don't know if this better than using new
There is a very specific reason for using HeapAlloc and nothing you posted suggests you need that.
And not a good idea to attempt to circumvent C++ compiler allocations unless you have identified a specific need and you understand exactly how allocations work.
If you have some limited need or just want to mess around then you can override allocations for a specific class (one class only) and control it in fine detail. And do so knowing that you are not as likely to mess up the rest of the application doing it.
Alternatively find several open source allocators and heaps and examine how they are implemented first to understand what happens with heaps.
Keep in mind that if you do attempt to control your own allocations you can completely destroy the application (runtime) because you can end up overwriting memory that has nothing to do with what you think it should. So do it very carefully.