For those new to message boards please try to follow a few simple rules when posting your question.
Choose the correct forum for your message. Posting a VB.NET question in the C++ forum will end in tears.
Be specific! Don't ask "can someone send me the code to create an application that does 'X'. Pinpoint exactly what it is you need help with.
Keep the subject line brief, but descriptive. eg "File Serialization problem"
Keep the question as brief as possible. If you have to include code, include the smallest snippet of code you can.
Be careful when including code that you haven't made a typo. Typing mistakes can become the focal point instead of the actual question you asked.
Do not remove or empty a message if others have replied. Keep the thread intact and available for others to search and read. If your problem was answered then edit your message and add "[Solved]" to the subject line of the original post, and cast an approval vote to the one or several answers that really helped you.
If you are posting source code with your question, place it inside <pre></pre> tags. We advise you also check the "Encode HTML tags when pasting" checkbox before pasting anything inside the PRE block, and make sure "Ignore HTML tags in this message" check box is unchecked.
Be courteous and DON'T SHOUT. Everyone here helps because they enjoy helping others, not because it's their job.
Please do not post links to your question in one forum from another, unrelated forum (such as the lounge). It will be deleted.
Do not be abusive, offensive, inappropriate or harass anyone on the boards. Doing so will get you kicked off and banned. Play nice.
If you have a school or university assignment, assume that your teacher or lecturer is also reading these forums.
No advertising or soliciting.
We reserve the right to move your posts to a more appropriate forum or to delete anything deemed inappropriate or illegal.
I'm generating dialog templates programmatically for a win32 project. A thing I often want to do is size the dialog box such that the distance between the left edge of the client region and the left edge of the leftmost control is the same as that between the right edge of the rightmost control and the right edge of the client region. Since the size of the dialog box as specified in the template, I believe, includes the non-client area, the only way I know of to do this is to use AdjustWindowRect on a RECT representing the desired client region. Since this requires the handle of the window being adjusted, I can't do it until after the dialog has been created. So I was wondering...if I can't ensure equal margins until runtime, how is it possible that one can use the GUI editor Visual Studio provides to create dialogs with equal margins ahead of time? I want to be able to do that too.
You can select a set of controls in the editor and then use the toolbar tool that centres the group in the dialog. There are tools to centre horizontally or vertically, make equidistant, align together etc.
Resizing at runtime is what I'm currently doing, and it's an acceptable solution, but if possible I would like to specify the size of the dialog in the template, which is generated before runtime, such that it's correct relative to the controls it contains to begin with, without need of resizing. The fact that the dialog editor can do this suggests that it is indeed possible somehow.
I did something like this a long time ago where I defined a dialog within a code module without the
ui editor and I think you will have to implement the use of DLGTEMPLATE which is used to define the dialog and all of the associated controls.
Take a look at InitModalIndirect() in the Mfc library dlgcore.cpp and I believe
there was some needed functions in occmgr.cpp that will help to some extent.
If you haven't used this structure before, it will required a bit of work.
Oh yes, I'm still on V2005 so if you have the latest visual studio there may be some changes.
Hope this is what you are looking for.
A blank empty dialog template centred in it's parent at runtime and done the way speedbump is suggesting is coded below. It is pretty straight forward you just need to allocate global memory block as the template and you can fill the controls in at initialization
int DialogFromTemplate (HWND parent, int DialogWth, int DialogHt, char* DlgTitle, DLGPROC handler)
int nchar, ret;
int x, y;
GetClientRect(parent, &r); // Get parent client area
x = ((r.right+r.left)/2); // Calc x client centre position
y = ((r.bottom+r.top)/2); // Calc y client centre position/* from the client centre the dialog left is half width and top half height less */
x -= DialogWth/2;
y -= DialogHt/2;
/* template size and position are in multiples of 2 .. yeah its weird */
x /= 2; // X client left position in template units
y /= 2; // Y client top position in template units
hgbl = GlobalAlloc(GMEM_ZEROINIT, 1024); // Allocate memoryif (!hgbl) return -1; // If allocate fail exit
lpdt = (LPDLGTEMPLATE)GlobalLock(hgbl); // Lock the allocated memory
lpdt->style = WS_POPUP | WS_CAPTION | WS_SYSMENU; // Window style
lpdt->cdit = 0; // Number of controls
lpdt->x = x; // X position
lpdt->y = y; // Y psoition
lpdt->cx = DialogWth/2; // Window width (template units)
lpdt->cy = DialogHt/2; // Window height (template units)
lpw = (LPWORD)(lpdt + 1); // Set pointer address
*lpw++ = 0; // No menu
*lpw++ = 0; // Predefined dialog box class (by default)
lpwsz = (LPWSTR)lpw; // Typecast pointer
nchar = 1 + MultiByteToWideChar(CP_ACP, 0, DlgTitle,
-1, lpwsz, 50); // Title of dialog
lpw += nchar; // Increment by size of name
*lpw++ = 0; // No creation data
GlobalUnlock(hgbl); // Release lock on the memory block
ret = (int)DialogBoxIndirectParam(GetModuleHandle(0),
(LPDLGTEMPLATE)hgbl, parent, Handler, 0); // Create the dialog from template
GlobalFree(hgbl); // Free the allocated memoryreturn ret; // Return result
Incorrect look at WM_INITDIALOG the message exists to do it. You simply move and resize the child windows before they become visible that is the whole point for the message to exist (read the message description). Everything is created but nothing has been drawn at that point. WM_INITDIALOG message - Windows applications | Microsoft Docs[^]
The OP didn't ask for that ... he asked for the ability to rescale a template or resource based dialog which we all do for high DPI apps because the inbuilt behaviour sucks.
Also for the record there are groups of controls that will do exactly what you have described they are called docking controls all you decide is where you want the anchor when you create them. I can easily give you a group of control that will automatically anchor themselves to the left side of a dialog it's trivial and CDockablePane in particular are often run that way in a dialog.
You can simply do a call to GetClientRect to get the parent area and change the dialog that is what the message is for. You can also use CreateDialogIndirectParam, CreateDialogParam, DialogBoxIndirectParam, or DialogBoxParam and pass
a pointer to the area or anything else you may want to do at runtime.
If you have not got access to the dialogs parent window handle you can get it by using the dialog handle with GetParent function | Microsoft Docs[^]
The dialog has been created and all functions on the handle work it just has not been made visible at that point.
You can also move and resize your child windows by handle or ID, they have all been created but nothing is visible at that point. You can also manually add child windows if you so desire at that point.
The WM_PAINT message to draw the dialog will be straight after that message and if it's a modal dialog it will then enter modal mode.
I am not sure how MFC encapsulates the WM_INITDIALOG probably ONINITDIALOG or something like that.
What I'm doing already is setting the using the size information in the dialog template to store the size I want the client region to be, then calling GetWindowRect, AdjustWindowRect, and MoveWindow from the WM_INITDIALOG implementation. From the answers I've gotten, it sounds like this is about the most direct solution I could hope for, which is good to know.
There are two parts to things positioning and scaling
Let me formally centre the dialog at runtime to it's parent in WM_INITDIALOG .. it is this simple
RECT R1, R2;
GetClientRect(GetParent(Wnd), &R1); // Parent client area
GetWindowRect(Wnd, &R2); // Dialog area
(R1.right+R1.left)/2 - (R2.right-R2.left)/2 , // Parent x centre - half dialog width
(R1.top+R1.Bottom)/2 - (R2.bottom-R2.top)/2, // Parent y centre - half dialog height0, 0, // No size data
SWP_NOSIZE | SWP_NOACTIVATE | SWP_NOZORDER);
Now if you want to centre and rescale generally you do the scale as a fraction to avoid floats
so (numerator/denominator) where denominator must not be zero
This usually works well because you have ( desired size / current size ) being the exact fraction
int Wth, Ht;
RECT R1, R2;
GetClientRect(GetParent(Wnd), &R1); // Parent client area
GetWindowRect(Wnd, &R2); // Dialog area
Wth = (R2.right-R2.left) * numerator; // Multiply dialog width by numerator
Wth /= denominator; // Divide dialog width by denominator
Ht = (R2.bottom-R2.top) * numerator; // Multiply dialog height by numerator
Ht /= denominator; // Divide dialog height by denominator
(R1.right+R1.left)/2 - Wth/2 , // Parent x centre - half scaled dialog width
(R1.top+R1.Bottom)/2 - Ht/2, // Parent y centre - half dialog height
Wth, Ht, // New sizes
SWP_NOACTIVATE | SWP_NOZORDER);// Do not change order or activate/* so if you want to scale the children windows you need to scale and move them *//* now go thru each child by id (shown as xxx) and scale and move them with this */
HWND cWnd = GetDlgItem(Wnd, xxxx); // Fetch and hold child handle from xxxx id
GetWindowRect(cWnd, &R3); // Fetch the child area
R3.left *= numerator; // Multiply child window left by numerator
R3.left /= denominator; // Divide child window left by denominator
R3.right *= numerator; // Multiply child window right by numerator
R3.right /= denominator; // Divide child window right by denominator
R3.top *= numerator; // Multiply child window top by numerator
R3.top /= denominator; // Divide child window top by denominator
R3.bottom *= numerator; // Multiply child window bottom by numerator
R3.bottom /= denominator; // Divide child window bottom by denominator
R3.left, // New child left
R3.top, // New child top
R3.right - R3.left, // New child width
R3.bottom - R3.top, // New child height
SWP_NOACTIVATE | SWP_NOZORDER); // Do not change order or activate
**Note you may also need to pass a scaled font (numerator/denominator) to some types of child window because you want the text bigger (you do that via WM_SETFONT).
My problem is that as I write larger and more complicated (C) programs, errors in manual memory management become much harder to find and more catastrophic, particularly if caused by memory corruption.
I'd like to detect any DMA related errors as quickly as possible perhaps only when a debug flag is #defined.
I pass a pointer to a pointer to the create and destroy object functions. Create will fail if a pointer to non NULL memory is passed which prevents doubly allocating.
I am thinking of storing pointers to all allocated objects in a balanced BST, which would enable me to tell if a pointer is valid before free()in it. After Free() I can write NULL to prevent it's use and to prepare it for allocation again.
Any function that wants to check if an object pointer is valid can then call a check of the BST inventory.
Further I was thinking of tagging each entry with a scope of some sort so that I can check for missed Free() as soon as the object is no longer used:
That way I can check at EndScope that all foobar scoped objects were freed.
This would enable me to make objects that were dynamically allocated have a stack based/automatic scope for example, if they are not going to be used after the function exits.
If using scopes for 'automatic' object allocation and nesting them in a stack, an error can be detected if a higher level scope is ended before a lower one.
These mechanisms are all intended to trigger errors as quickly as a problem can be detected and before it worsens. And furthermore to do so with the most minimal burden on the user.
I couldn't find a standard practice because garbage collection does not seem to be the same concept as detecting errors in memory management.
Is this good? Is there a better way of doing it / standard practice?
When you code reaches a certain complexity you have to stop and implement test benches on each unit file .. I take it you are not doing so.
At the moment you are treating the symptoms not the cause.
Put simply your
Should be known to work bug free because it passes your benchtest unit with clear use guideline API
One of the things writing the bench test unit does is makes you stop and think about possible errors because you try to bench test the errors.
Your bench test code should obviously include malloc failing and all memory writes should be checked for size in the benchtest. So put bluntly
your code is failing because you are failing to test properly.
For even larger projects especially if threaded it often becomes necessary to use a MOCK framework to actually cross test the units together.
Typical test frameworks are listed in the C section of List of unit testing frameworks - Wikipedia[^]
The more common ones are CMock, Ceedling and Unity.
Many memory problems come from inherent issue with pointers that lets you copy the reference to an allocated object without restriction, but then doesn't let these references track when someone deletes it. Neither indirection nor garbage collection can solve that. Instead, use smart pointers!
Smart pointers behave for the most part like normal pointers, but they also make sure that the allocated objects get released when they are no longer referenced. And not earlier!
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
Hi, I'm new to Socket Programming, I don't know how to create a NamedPipe Server and Client Application, Here My requirement is below
1.) Create multithreaded pipe server and pipe Client inter-process sample application VC++/MFC.
2.) Transfer unsigned Char arr dummy bytes to and fro pipe client.
3.) Result display in printf both side.
By using VC++ or MFC Classes,