I am learning Win32 API programming. I read this paragraph, it says:
https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-systemparametersinfoa
SPI_SETMOUSETRAILS
Enables or disables the Mouse Trails feature, which improves the visibility of mouse cursor movements by briefly showing a trail of cursors and quickly erasing them.
To disable the feature, set the uiParam parameter to zero or 1. To enable the feature, set uiParam to a value greater than 1 to indicate the number of cursors drawn in the trail.
Windows 2000: This parameter is not supported.
I tried to write the following code:
#include <windows.h>
int main(int argc, char *argv[], char *envp[])
{
//SystemParametersInfo(SPI_SETMOUSETRAILS, NULL,(PVOID)10, 0);
SystemParametersInfo(SPI_SETMOUSETRAILS, NULL,(PVOID)0, 0);
}
But it doesn't seem to make a difference.
Can anyone tell me how this macro works? I couldn't find an example on the Internet, so I am asking here.
Read the documentation again more carefully:
To disable the feature, set the uiParam parameter to zero or 1. To enable the feature, set uiParam to a value greater than 1 to indicate the number of cursors drawn in the trail.
Look at the declaration of the function:
BOOL SystemParametersInfoA(
UINT uiAction,
UINT uiParam,
PVOID pvParam,
UINT fWinIni
);
Your code is setting the uiParam parameter to 0 (disabling the feature), and setting the pvParam parameter to the cursor count (which is ignored).
Try this instead:
#include <windows.h>
int main(int argc, char *argv[], char *envp[])
{
UINT cursorCount = ...;
SystemParametersInfo(SPI_SETMOUSETRAILS, cursorCount, NULL, 0);
return 0;
}
I couldn't find an example on the Internet
Really? When I enter just SPI_SETMOUSETRAILS by itself into Google, literally the 1st link returned contains an example:
http://ntcoder.com/bab/tag/spi_setmousetrails/
SystemParametersInfo is a powerful function which does and retrieves whole lot of things related to windows general behavior for eg: turning on and off certain features like mouse trails which we normally do via control panel->main.cpl
Look up MSDN for more information on SystemParametersInfo. I’ll just show a demo on how to turn on and off mouse trails…
// Turn on mouse trails, showing 10 cursors drawn in the trail
SystemParametersInfo( SPI_SETMOUSETRAILS, 10, 0, 0 );
// Turn off mouse trails, set trail count to 1 or zero to disable trails
SystemParametersInfo( SPI_SETMOUSETRAILS, 1, 0, 0 );
Related
I'm a bit unsure of the meaning of some of the return values from a call to the GetWindowPlacement() function, so I'd like your help, please.
I'll be calling this to obtain the normal dimensions of a hidden window.
First, where do the values of the showCmd field come from? In the Microsoft documentation of the return structure (WINDOWPLACEMENT structure, all the descriptions of the possible values use verbs/action words; e.g., "SW_MAXIMIZE: Maximizes the specified window", or "SW_SHOWNOACTIVATE: Displays a window in its most recent size and position."
I want to obtain the dimensions of the hidden window without unhiding/restoring it first, so with the verbs it seems that I would have to call SetWindowPlacement() with showCmd set to SW_SHOWNOACTIVATE before calling GetWindowPlacement. Is that correct?
So do I understand correctly that the primary (and perhaps only) way that field gets its various values is by an explicit call to SetWindowPlacement() somewhere?
My second question relates to the rcNormalPosition return values. Do those data include the window decorations, or are they client values?
Thank you for your time!
The meaning of the showCmd member of the WINDOWPLACEMENT struct is a bit confusing because Win32 is reusing the SW_* commands used by ShowWindow().
Luckily, the meaning is documented on the GetWindowPlacement() function.
If the window identified by the hWnd parameter is maximized, the
showCmd member is SW_SHOWMAXIMIZED. If the window is minimized,
showCmd is SW_SHOWMINIMIZED. Otherwise, it is SW_SHOWNORMAL.
So, based on which of those 3 values is returned, you can tell whether the window is currently maximized, minimized or, normal (restored). And if you'd like to know what the normal placement is, you can just use the rcNormalPosition member. You do not need to call SetWindowPlacement() at all.
However, heed the warning that GetWindowPlacement() returns workspace coordinates rather than screen coordinates, which differ based on taskbar position and size. This is not a problem if you are only using the coordinates returned by GetWindowPlacement() to call SetWindowPlacement(). Otherwise, you might have to find a way to convert from workspace to screen coordinates.
I found these 2 functions to work for me.
void MyDialog::LoadDialogPlacement()
{
static WINDOWPLACEMENT last_wp = {};
// Load last stored DB version
WINDOWPLACEMENT *wp = new WINDOWPLACEMENT;
GetStoredWindowPlacement(&wp);
if (memcmp((void *)&last_wp, (const void *)wp, sizeof(WINDOWPLACEMENT)) == 0) return;
memcpy((void *)&last_wp, (const void *)wp, sizeof(WINDOWPLACEMENT));
SetWindowPlacement(wp);
delete[] wp;
}
void MyDialog::SaveDialogPlacement()
{
static WINDOWPLACEMENT last_wp = {};
if (IsWindowVisible())
{
WINDOWPLACEMENT wp = {};
wp.length = sizeof(WINDOWPLACEMENT);
GetWindowPlacement(&wp);
if (memcmp((void *)&last_wp, (const void *)&wp, wp.length) == 0) return;
memcpy((void *)&last_wp, (const void *)&wp, wp.length);
StoreWindowPlacement(&wp);
}
}
The following code opens a window of the right size, w,h, but not at the correct position, x,y.
#include <iostream>
#include <X11/Xlib.h>
#include <X11/Xutil.h>
#include <X11/Xresource.h>
using namespace std;
int main(int argc, char* argv[]){
Display *display; // A connection to X server
int screen_number;
Window canvas_window;
unsigned long white_pixel;
unsigned long black_pixel;
display = XOpenDisplay(NULL); // Connect X server by opening a display
if(!display){
cerr<<"Unable to connect X server\n";
return 1;
}
screen_number = DefaultScreen(display);
white_pixel = WhitePixel(display, screen_number);
black_pixel = BlackPixel(display, screen_number);
int x=0, y=100, w=300, h=400;
canvas_window = XCreateSimpleWindow(display,
RootWindow(display, screen_number),
x,y, // top left corner
w,h, // width and height
2, // border width
black_pixel,
white_pixel);
XMapWindow(display, canvas_window); // Map canvas window to display
XSync(display, False);
cin >> x; // just so that the program does not end
}
I compiled this with g++ xwindowtest.cpp -lX11 where g++ is version 4.6.2 and ran under Debian GNU/Linux.
The above solution is sort of correct, but not complete.
Creating a new top-level window on the desktop, and creating a new (child) window within the top-level window of your application use the same XCreateSimpleWindow() call, but the actual behaviour can be different.
When creating a new child window within your application you are in charge, and the origin coordinates (relative to its parent window's origin) and size you give for the new window will be honoured. In other words the window will go where you want it to.
However when creating a new top-level window on the desktop you have to deal with the pesky window manager, for example Motif, KDE, Gnome, etc. This intervenes when you create a top-level window to add borders ("decoration"), title, possibly icons, etc. More to the point it will, by default, ignore your requested origin coordinates in most cases and put the new window where it wants rather than where you asked it to put it. It is only when it has been mapped (somewhere) that you can then move it with XMoveWindow().
To avoid this you can ask, or in X11-speak "Hint to", the Window manager that "no, I want you to put the window where I ask, not where you want to put it". You do this with the following sequence:
(1) Define a XSizeHints structure.
(2) Set the flags bit in this structure with a mask of what you want to specify
(3) Populate the relevant arguments
(4) Call XSetNormalHints() on the newly created window (before you map it).
So in C code you would do:
XSizeHints my_hints = {0};
my_hints.flags = PPosition | PSize; /* I want to specify position and size */
my_hints.x = wanted_x_origin; /* The origin and size coords I want */
my_hints.y = wanted_y_origin;
my_hints.width = wanted_width;
my_hints.height = wanted_height;
XSetNormalHints(disp, new_window, &my_hints); /* Where new_window is the new window */
Then map it and - hopefully - it will be where you want it.
I usually declare a XSizeHints first and assign x,y coordinates etc to hints.
When creating x window you could do
XCreateSimpleWindow(display,
DefaultRootWindow(display),
hints.x, hints.y,
hints.width,hints.height,
borderWidth,
blackPixel, whitePixel)
That always works for me with 100% correct windows location.
I had the same problem. I am just starting with X11. Maybe others with more experience can clarify why this works (and simply specifying the x, y for XCreateSimpleWindow does not).
Here's my fix:
disp is your display, win0 is your canvas_window:
XMoveWindow(disp, win0, 200, 200);
XSync (disp, FALSE);
..... do something .....
XMoveWindow(disp, win0, 0, 0);
XSync (disp, FALSE);
... do something
When I run this code snippet, the window moves. You need to follow the XMoveWindow by XSync so that requests (such as a move) are handled appropriately.
I've been searching the net for different things about the win32 API, but it seems all information on it is rather sparse.
I am looking to create a simple window that shows a list of items, however I want to display different columns of data for each item, in a table-style format, where the user could perhaps be allowed to resize the different column widths.
If at all possible, I'd like to also be able to change the background colors of different rows, in the code, between just a general white, red, yellow, or green.
And the user would also be allowed to right click different rows, and be able to call a function on them, or copy the data to the clipboard (but that part is a different story).
Now, I've found list-viewer objects(?) that can be placed in the window, buttons, and right-click menus... but I cannot figure out how to do a table, using the Win32 API. I haven't even really read up on background colors for anything other than the window itself, either.
Is there a different, better framework I should use for this, or are there some functions or items that I've been missing? All help or guidance on the idea would be appreciated...
I'm using MSVC++ to do... everything that I'm working on.
Using the windows API and the standard control ListView you can do a table using the style LVS_REPORT
documentation link - unfortunatelly with no code :( -
About List-View Controls
I've found this good article Windows Programmierung: List View
the explanation is in german language but a google translation together with the code should be enough to understand it. From the article, to create the window:
#include "commctrl.h"
InitCommonControls();
hwndList = CreateWindow(WC_LISTVIEW, "",
WS_VISIBLE|WS_BORDER|WS_CHILD | LVS_REPORT | LVS_EDITLABELS,
10, 10, 300, 100,
hWnd, (HMENU)ID_LIST, hInst, 0);
then it is explained how to create the columns in the method
int CreateColumn(HWND hwndLV, int iCol, char *Text, int iWidth)
how to insert an item (one column)
int CreateItem(HWND hwndList, char *Text)
or insert item with two columns
int Create2ColItem(HWND hwndList, char *Text1, char *Text2)
etc...
Windows provides a fairly basic collection of built-in controls, listed here.
If you want something more sophisticated your options are:
Code it yourself. You have to paint it yourself, handle all the user-interaction, the scrolling, etc. This is a big job.
Find an existing implementation.
Abandon VC++ and use WinForms or WPF.
If you're stuck with VC++, The Grid Control and The Ultimate Grid are MFC-based.
If you're not using MFC there's BABYGRID or The Win32 SDK Data Grid.
If none of them suit, you'll have more luck searching for "grid" than "table".
For Listview examples, nothing beats the clarity of the Classic Sample!
In the meantime, Google Translate along with Unicode + tiny modifications to the rescue for #Alejadro's German link for the Listview- there's no direct translation on offer from search results as the page doesn't contain the appropriate meta tag. Snipped a little for brevity:
Subsequent changes of styles
The style of a ListView can be changed after creation. For this the functions GetWindowLong and SetWindowLong are used. About masks different styles can be defined.
Mask.................................Masked Styles:
LVS_TYPEMASK..............LVS_ICON, LVS_LIST, LVS_REPORT and LVS_SMALLICON
LVS_ALIGNMASK.............LVS_ALIGNLEFT and LVS_ALIGNTOP
LVS_TYPESTYLEMASK...LVS_ALIGNLEFT and LVS_ALIGNTOP but also VS_NOCOLUMNHEADER and LVS_NOSORTHEADER
For the following sequence, dwView contains the style to use, such as LVS_REPORT or LVS_ICON.
DWORD dwStyle = GetWindowLong(hwndLV, GWL_STYLE); // get current style
if ((dwStyle & LVS_TYPEMASK)! = dwView) // only on change
SetWindowLong(hwndLV, GWL_STYLE, (dwStyle & ~ LVS_TYPEMASK) | dwView); }
Control of the ListView control
Generating a list
A list view is created with the CreateWindow function. The window class uses the constant WC_LISTVIEW. To do this, the common control header file must be included.
#include "commctrl.h"
InitCommonControls();
hwndList = CreateWindow(WC_LISTVIEW, "",
WS_VISIBLE | WS_BORDER | WS_CHILD | LVS_REPORT | LVS_EDITLABELS,
10, 10, 300, 100,
hWnd, (HMENU) ID_LIST, hInst, 0);
In the dialog, it is simply defined in the resource.
If there are unresolved externals, you should check whether the library for the Common Controls (comctl32.lib) is included.
Columns of the ListView
Before something can be inserted in a REPORT, the columns must be defined. A column is described by the structure LVCOLUMN. The following routine creates a column.
int CreateColumn(HWND hwndLV, int iCol, char * text, intwidth)
{
LVCOLUMN lvc;
lvc.mask = LVCF_FMT | LVCF_WIDTH | LVCF_TEXT | LVCF_SUBITEM;
lvc.fmt = LVCFMT_LEFT;
lvc.cx = iWidth;
lvc.pszText = text;
lvc.iSubItem = iCol;
return ListView_InsertColumn(hwndLV, iCol, & lvc);
}
The columns can be modified by messages to the ListView or by calling macros that will ultimately execute a SendMessage.
Message Macro call Function
LVM_INSERTCOLUMN ListView_InsertColumn(HWND, int, LVCOLUMN * ) Insert column
LVM_DELETECOLUMN ListView_DeleteColumn(HWND, int) Delete column
LVM_GETCOLUMN ListView_GetColumn(HWND, int, LVCOLUMN * ) Get properties of the column
LVM_SETCOLUMN ListView_SetColumn(HWND, int, LVCOLUMN * ) Change properties of the column
LVM_GETCOLUMNWIDTH ListView_GetColumnWidth(HWND, int) Determine column width
LVM_SETCOLUMNWIDTH ListView_SetColumnWidth(HWND, int, int) Set column width
Insert a line
An element of the ListView is described by the structure LVITEMW (see below). Each element can be represented as an ICON, SMALLICON, LIST element or as the left column of a REPORT line.
int CreateItem(HWND hwndList, wchar_t * text)
{
LVITEMW lvi = {0};
lvi.mask = LVIF_TEXT;
lvi.pszText = text;
return ListView_InsertItem(hwndList, & lvi);
}
The mask field determines which elements of the LVITEMW structure are really used. Since it often makes sense to keep a pointer to the memory object that holds the data behind the object, the lParam field is useful. In order for this to be used, LVIF_TEXT | LVIF_PARAM must be set as a mask.
The constants of mask and the fields that enable them:
LVIF_IMAGE iImage
LVIF_INDENT iIndent
LVIF_PARAM lParam
LVIF_STATE state
LVIF_TEXT pszText
The further columns of a report
The element itself is always left in the report view and is selectable. To fill more columns, a text is added to the item.
int Create2ColItem(HWND hwndList, wchar_t * Text1, wchar_t * Text2)
{
LVITEMW lvi = {0};
int Ret;
// Initialize LVITEMW members that are common to all items.
lvi.mask = LVIF_TEXT;
lvi.pszText = Text1;
Ret = ListView_InsertItem(hwndList, & lvi);
if (Ret >= 0)
{
ListView_SetItemText(hwndList, Ret, 1, Text2);
}
return Ret;
}
The above Create2ColItem is best demonstrated by something along the line of the following statements:
LVHwnd = Your_Create_LV_Routine();
if (LVHwnd)
{
CreateColumn(LVHwnd, 0, ptrColHeaderString1, iColSize1);
CreateColumn(LVHwnd, 1, ptrColHeaderString2, iColSize2);
Create2ColItem(LVHwnd, ptrItemText1, ptrItemText2);
}
The structure LVITEMW
The structure LVITEMW (in CommCtrl.h) describes an element of the ListView. The most important elements are briefly described here. First the definition:
typedef struct tagLVITEMW
{
UINT mask;
int iItem;
int iSubItem;
UINT state;
UINT stateMask;
LPWSTR pszText;
int cchTextMax;
int iImage;
LPARAM lParam;
#if (_WIN32_IE >= 0x0300) //historical note for IE3 users!
int iIndent;
#endif
#if (NTDDI_VERSION >= NTDDI_WINXP)
int iGroupId;
UINT cColumns; // tile view columns
PUINT puColumns;
#endif
#if (NTDDI_VERSION >= NTDDI_VISTA)
int* piColFmt;
int iGroup; // readonly. only valid for owner data.
#endif
} LVITEMW, *LPLVITEMW;
The LVM_GETITEMW and LVM_SETITEMW messages change the attributes of an element. As a parameter, you get a pointer to a LVITEMW structure next to the HWND of the ListView, which must be filled in advance.
The structural elements in detail:
Mask:
Specifies which elements are used. A combination of the following flags is possible:
LVIF_IMAGE iImage
LVIF_INDENT iIndent
LVIF_PARAM lParam
LVIF_STATE state
LVIF_TEXT pszText
iItem
Index (0-based) of the item to which the structure relates.
iSubItem
Index (1-based) of the subitem to which the structure relates. 0 if the structure refers to an item instead of a subitem.
pszText
points to a null-terminated string. If the value is LPWSTR_TEXTCALLBACK, it is a callback item. If this changes, pszText must be set to LPSTR_TEXTCALLBACK and the ListView informed by LVM_SETITEMW or LVM_SETITEMTEXT.
pszText must not be set to LPWSTR_TEXTCALLBACK if the ListView has the style LVS_SORTASCENDING or LVS_SORTDESCENDING.
cchTextMax
Size of the buffer when the text is read.
iImage
Index of the icon of this element from the image list.
lParam
32-bit value that is specific to this element.
Actions with elements
LVM_INSERTITEM Insertion of an element
LVM_DELETEITEM Delete an element
LVM_DELETEALLITEMS Delete all elements
LVM_GETITEMW Read properties of the element
LVM_GETITEMTEXT Read text of the element
LVM_SETITEMW change
LVM_SETITEMTEXT Change to the text
Before inserting multiple items, an LVM_SETITEMCOUNT message will be sent to the ListView indicating how many items will ultimately be contained. This allows the ListView to optimize its memory allocation and release. How many elements a ListView contains can be determined with LVM_GETITEMCOUNT.
Editing selected elements
int Pos = -1;
LVITEMW Item;
Pos = ListView_GetNextItem(hwndList, Pos, LVNI_SELECTED);
while (Pos> = 0)
{
Item.iItem = Pos;
Item.iSubItem = 0;
ListView_GetItem(hwndList, & Item);
TuWasMitElement((Element Type * ) Item.lParam);
Pos = ListView_GetNextItem(hwndList, Pos, LVNI_SELECTED);
}
Events
The ListView sends WM_NOTIFY messages to the parent window. The code can take the following values:
Message............ Description
LVN_BEGINDRAG.............Start a drag-and-drop action
LVN_BEGINRDRAG..........Start a drag-and-drop action with the right mouse button
LVN_BEGINLABELEDIT....Start editing a label
LVN_ENDLABELEDIT.......End edit of a label
LVN_DELETEITEM..........Reports that the item is deleted
LVN_DELETEALLITEMS..Reports that all items are deleted
LVN_COLUMNCLICK......Indicates that the user clicked in the header of a report display
LVN_GETDISPINFO.......The control requests information about the presentation from the parent window
LVN_SETDISPINFO.......The information of the parent window for the item must be renewed
LVN_INSERTITEM..........Indicates the insertion of an item
LVN_ITEMCHANGED.....Indicates that an item has been changed
LVN_ITEMCHANGING....Indicates the intended change of an item
LVN_KEYDOWN.............Key was pressed
Editing the labels
The list view must have been created using the LVS_EDITLABELS style. Then a label can already be clicked on and inputs are accepted. However, the input is discarded immediately afterwards. To allow changes in the label, you just need to catch the WM_NOTIFY and return TRUE. In order to access the entered text in between, access is made to the text of the item. The example shows the input in a message box.
case WM_NOTIFY:
switch (((LPNMHDR) lParam) -> code)
{
case LVN_ENDLABELEDIT:
pItem = (NMLVDISPINFO) lParam;
MessageBox (hWnd, pItem-> item.pszText, "entry", MB_OK);
return TRUE;
If editing was aborted, the pszText element will be 0.
If you want to prevent editing, the message LVN_BEGINLABELEDIT is caught and returned TRUE. Here, too, the item can be accessed in the same way via lParam and thus, for example, a certain item group can be excluded.
Click on the column header in the ListView
case WM_NOTIFY:
switch (((LPNMHDR) lParam) -> code)
{
case LVN_COLUMNCLICK:
ColumnNr = ((LPNMLISTVIEW) lParam) -> iSubItem;
.....
Selection Event
The LVN_ITEMACTIVATE event is sent when the user activates an item. As with the other ListView events, it achieves the window function as part of a WM_NOTIFY message.
case WM_NOTIFY:
switch (((LPNMHDR) lParam) -> code)
{
case LVN_ITEMACTIVATE:
HWND hwndFrom = (HWND) ((LPNMHDR) lParam) -> hwndFrom;MarkedItemIndex =
ListView_GetNextItem(hwndFrom, -1, LVNI_SELECTED);
.....
The LVM_GETSELECTEDCOUNT message can be used to determine how many items have been activated. The LVM_GETNEXTITEM message is sent with the LVNI_SELECTED attribute and all items have been edited.
I have a callback for the size-allocate signal on my GtkScrolledWindow. I want to scroll to the right when I am adding stuff to that window. This works fine but introduces a subtle bug when removing items from that window. I would like to only scroll the window when adding stuff. I see the signal receives a GdkRectangle but I am unsure how to use it.
First size-allocate signal run-first, that means, If I'm not wrong, before the default handler. So you can get the GdkRectangle of the widget with gtk_widget_get_allocation, and compare it with the new one.
Now GdkRectangle is a cairo_rectangle_int_t and the definition of that is:
typedef struct {
int x, y;
int width, height;
} cairo_rectangle_int_t;
So you can check width and heights, with the old ones.
What?
I have a DLGTEMPLATE loaded from a resource DLL, how can I change the strings assigned to the controls at runtime programmatically?
I want to be able to do this before the dialog is created, such that I can tell that the strings on display came from the resource DLL, and not from calls to SetWindowText when the dialog is initialized.
Google has found examples of creating DLGTEMPLATE in code, or twiddling simple style bits but nothing on editing the strings in memory.
How?
I am doing this by hooking the Dialog/Property Sheet creation API's. Which gives me access to the DLGTEMPLATE before the actual dialog is created and before it has a HWND.
Why?
I want to be able to do runtime localization, and localization testing. I already have this implemented for loading string (including the MFC 7.0 wrapper), menus and accelerator tables, but I am struggling to handle dialog/property sheet creation.
Code examples would be the perfect answer, ideally a class to wrap around the DLGTEMPLATE, if I work out my own solution I will post it.
You can't edit the strings in memory. The DLGTEMPLATE structure is a direct file mapping of the relevent bytes of the resource dll. Thats read only.
You are going to need to process the entire DLGTEMPLATE structure and write out a new one with the altered length strings.
It will frankly be easier to just hook the WM_INITDIALOG and alter the strings by interacting with the controls than building a DLGTEMPLATE writer. Because there arn't a lot of those around. Unless you have an additional requirement to actually save altered dialog resources to disk as raw .res files (or attempt to modify the .dll inplace) Id really recommend you avoid this approach.
You say you are already doing this for accellerator tables and menu strings - if you can guarantee that the patched in strings are going to be shorter, then just make a binary copy of the DLGTEMPLATE struct, and write the non trivial scanning code necessary to find each string so you can patch the copy in place.
There is a file out there somewhere (which I think originated at Microsoft but I am not completely sure) called RESFMT.ZIP which explains this with some code examples. Raymond Chen also does some excellent explanations of this on his blog. Note that the format of DIALOGEX and DIALOG controls are different.
As noted in some other answers you would need to create the structure again from the start. This isn't all bad as you already have the basic information. Adding the controls is where is gets hard.
Basically, allocate a largish block of memory into a WORD *lpIn. Then add the structure up on top of that. adding the basic information for the DIALOG (see DLGTEMPLATE) and the controls is pretty obvious as the information is there in MSDN.
The two biggest problems you will encounter are: Making sure that the various part start on an alignment boundary, and interpreting the values of DIALOG controls, especially when to add a just a string or, a string or ordinal. Each control needs to start on an even boundary.
For the first (borrowed from somewhere I think RESFMT.ZIP):
WORD *AlignDwordPtr (WORD *lpIn)
{
ULONG ul;
ul = (ULONG) lpIn;
ul +=3;
ul >>=2;
ul
What I did was build a series of functions like this one following that allowed me to assemble DIALOGS in memory. (My need was so I could have some common code that didn't need an associated RC file for some very basic messages).
Here is an example...
WORD *AddStringOrOrdinalToWordMem( WORD *lpw, char *sz_Or_Ord )
{
LPWSTR lpwsz;
int BufferSize;
if (sz_Or_Ord == NULL)
{
*lpw++ = 0;
}
else
{
if (HIWORD(sz_Or_Ord) == 0) //MAKEINTRESOURCE macro
{
*lpw++ = 0xFFFF;
*lpw++ = LOWORD(sz_Or_Ord);
}
else
{
if (strlen(sz_Or_Ord))
{
lpwsz = ( LPWSTR ) lpw;
BufferSize = MultiByteToWideChar( CP_ACP, 0, sz_Or_Ord, -1, lpwsz, 0 );
MultiByteToWideChar( CP_ACP, 0, sz_Or_Ord, -1, lpwsz, BufferSize );
lpw = lpw + BufferSize;
}
else
{
*lpw++ = 0;
}
}
}
return( lpw );
}
The header file to the complete module included these functions:
WORD *AddControlToDialogTemplateEx(MTDialogTemplateType *dlgtmp,
char *Title,
WORD Id,
char *WinClass,
DWORD Style,
short x,
short y,
short cx,
short cy,
DWORD ExStyle,
int HelpID);
int DestroyDlgTemplateEx(MTDialogTemplateType *dlgtmp);
MTDialogTemplateType *CreateDlgTemplateEx( char *Name, // We use name just for reference, so it can be NULL
short x,
short y,
short cx,
short cy,
DWORD ExtendedStyle,
DWORD Style,
char *Menu,
char *WinClass,
char *Caption,
char *FontTypeFace,
int FontSize,
int FontWeigth,
int FontItalic,
int Charset,
int HelpID,
int NumberOfControls);
Which allowed me to assemble whole dialogs easily from code.
See the API function ::EnumChildWindows( HWND, WNDENUMPROC, LPARAM )
You can call this in a CFormView::Create or CDialog::OnInitDialog to give yourself a chance to replace the control captions. Don't worry, the old strings don't flicker up before you replace them.
In your dialog resource, set the control captions to a key in some kind of dictionary. If you're compiling /clr you can use a managed string table resource. In your callback, look up the translated string in your dictionary and set the control's caption to the translation. Another benefit of /clr and managed string table is that you can automatically look up the right language by Windows (or you) having already set System::Threading::Thread::CurrentThread->CurrentUICulture.
Something like this
CMyDialog::OnInitDialog()
{
::EnumChildWindows(
this->GetSafeHwnd(),
CMyDialog::UpdateControlText,
(LPARAM)this )
}
BOOL CALLBACK CMyDialog::UpdateControlText( HWND hWnd, LPARAM lParam )
{
CMyDialog* pDialog = (CMyDialog*)lParam;
CWnd* pChildWnd = CWnd::FromHandle( hWnd );
int ctrlId = pChildWnd->GetDlgCtrlID();
if (ctrlId)
{
CString curWindowText;
pChildWnd->GetWindowText( curWindowText );
if (!curWindowText.IsEmpty())
{
CString newWindowText = // some look up
pChildWnd->SetWindowText( newWindowText );
}
}
}
You'll have to locate the string you want to modify in the mem buffer that represents the template. The only way to do that is to traverse the whole template. Which is not easy.
Once you've done that, either insert bytes in the buffer if your new string is longer than the original one. Or shrink the buffer if the new string is shorter.
As Chris wrote, it would be much easier to modify the text in WM_INITDIALOG and try to re-phrase you requirement that says you may not call SetWindowText().
Thanks all, I actually had 24 hours rest on the problem, then went with a global windows hook filtering WM_INITDIALOG which was a much simpler method, worked out just fine, no API hooking required, 2 pages of code down to just a few lines.
Thanks for all the answers.