First of all, please bear in mind that I'm new to Windows Programming. I'll try to cover my question in great detail, so that hopefully the answer will be too.
A short introduction:
I'm copying writing a Notepad-like application using Win32 API and pure C. For those of you familiar with Petzold's Windows Programming, this is a modified version of his POPPAD program which he used to describe Common Dialog Boxes. I'm writing this strictly for educational purposes, so please refrain from posting comments like "why you using old technology, use .NET", as those comments will not help me solve my problem :).
Description of a problem:
Petzold in his POPPAD program used Common Dialog Boxes to write this Notepad-like application. He used Edit Control to provide all the functions of a basic text editor. POPPAD, much like a Notepad, also had Find and Replace dialog boxes where you could, well, find stuff AND replace it! Mind boggling, I know.
So this is where I wanted to test my newly acquired knowledge from reading the past chapters, as I decided to write my very own Find and Replace dialog box. Granted, it would be in the simplest form possibly. How hard can it be? You have one text field where you enter some text and you have one fancy button which says "Find!" on it.
Now I'd like to remind you once more that I'm new to Windows programming, so excuse me for any possibly newbie questions. Also, I'd like to point out that I'll focus solely on making the Find dialog box working, as Replace shouldn't be too hard to implement then.
So I played with the resource editor in Visual Studio, and few hours later I got this:
(stackoverflow doesn't actually allows me to post images, so here's the link below)
http://i.imgur.com/R98x4.png
I named this dialog box "Find" (with the quotation marks), so I don't have to use MAKEINTRESOURCE macro in my program, as per Petzold's school of thought. I changed the caption of "Ok" button to "Find Next" and changed it's ID from IDOK to IDC_FIND. Also changed IDCANCEL to IDC_CANCEL and that single line Edit Control is IDC_FIND_FIND.
Now to the more serious things. In my main program's Windows Procedure, I have this piece of code:
case IDM_SEARCH_FIND:
hDlgModeless = CreateDialog (hInst, TEXT ("Find"),
hwnd, FindDlgProc) ;
return 0 ;
IDM_SEARCH_FIND is a message identifier of a Menu item, which when clicked should open up the Find dialog box. CreateDialog function is used to create a modeless dialog box and store it's handle into a global variable hDlgModeless. FindDlgProc is name of the dialog box procedure where (I think) all the code of finding the text should go.
So without further ado, here's the code of my Find dialog box procedure:
BOOL CALLBACK FindDlgProc (HWND hDlg, UINT message,
WPARAM wParam, LPARAM lParam)
{
static TCHAR szFindWhat[MAX_STRING_LEN]; //Text to find
static int iOffset ; //Offset from the beginning of Edit control to the result
int iLength, iPos, iSingleLength ; //Length of a main Edit control and single line Edit control
PTSTR pstrDoc, pstrPos ;
switch (message)
{
case WM_INITDIALOG:
return TRUE ;
case WM_COMMAND:
switch (LOWORD (wParam))
{
//If the button "Find Next" has been pressed, process all the logic of finding the text
case IDC_FIND:
// Get the text from a single-line edit control in Find dialog box
// and save it in szFindWhat variable
iSingleLength = GetWindowTextLength(GetDlgItem(hDlg, IDE_FIND_FIND)) ;
GetWindowText(GetDlgItem(hDlg, IDE_FIND_FIND), szFindWhat, iSingleLength) ;
// Get the text from a main Edit control, allocate memory for it
// and store it in pstrDoc variable
iLength = GetWindowTextLength (hwndEdit) ;
if (NULL == (pstrDoc = (PTSTR) malloc ((iLength + 1) * sizeof (TCHAR))))
return FALSE ;
GetWindowText (hwndEdit, pstrDoc, iLength + 1) ;
// Search the document for the find string
pstrPos = _tcsstr (pstrDoc + iOffset, szFindWhat) ;
free (pstrDoc) ;
// Return an error code if the string cannot be found
if (pstrPos == NULL)
return FALSE ;
// Find the position in the document and the new start offset
iPos = pstrPos - pstrDoc ;
iOffset = iPos + lstrlen (szFindWhat) ;
// Select the found text
SendMessage (hwndEdit, EM_SETSEL, iPos, iOffset) ;
SendMessage (hwndEdit, EM_SCROLLCARET, 0, 0) ;
case IDC_CANCEL:
DestroyWindow (hDlg) ;
hDlgModeless = NULL ;
break ;
}
break ;
case WM_CLOSE:
DestroyWindow (hDlg) ;
hDlgModeless = NULL ;
break ;
default:
return FALSE;
}
return FALSE ;
}
The only actual error I get here is that hwndEdit is undeclared identifier. hwndEdit is the main Edit control (not the single-line in Find dialog box). How do I get the handle to hwndEdit while I'm in a Find dialog box procedure?
I'd like to point out that I'm feeling a bit over my head here, so please say if I'm missing/doing wrong something obvious. I'm pretty sure that even if I fix the only error I'm getting, the program still won't work. Even though the concept of what I should be doing sounds fairly simple, actually programming that seems quite difficult :)
This is what the code above should do, in simplest form:
- Get the text from Find dialog box which I wish to search
- Get the text from main Edit control
- Do a substring search from the last offset (don't start from beginning every time)
- Find the position of a result and readjust offset
- Select the found text
I know I haven't really asked a direct question here, well I guess the direct question would be: How do I make this work? :) But more importantly it would be to understand how this exactly works. I'd appreciate if you can provide me with an elaborate answer. Thanks for all the help!
It looks like you're very close, you just need to get the hwndEdit from your main window. You passed your main window's handle in as a parent to your dialog box, so you should be able to get the parent window of your dialog box like so:
HWND hwndParent = GetParent(hDlg);
After that you can get the edit control from that parent by referencing the edit control ID in your main window definition. Something like this (assuming the control ID is IDC_EDIT):
HWND hwndEdit = GetDlgItem(hwndParent, IDC_EDIT);
Related
I have a Tizen Edje file which defines my layout. One part is an image with part name 'warning'. The item is set to visible in the edge file, and it shows as expected.
I want to hide this part using C code:
Evas_Object* image_NotSetYet = (Evas_Object *) edje_object_part_object_get(elm_layout_edje_get(wid->edjeLayout), "warning");
if (image_NotSetYet == NULL) {
dlog_print(DLOG_ERROR, LOG_TAG, "View: Unable to get warning image part");
return;
}
evas_object_hide(image_NotSetYet);
I have tried many different ways to get the Evas Object associated with this part name and hide it. After many hours I stumbled onto some code that I modeled after, and it seems to work. I can hide (and show) my image part now.
However, I later add an unrealted image to a swallow in this layout and show it. All of a suddent the 'warning' part image shows again. Why? Am I hiding the 'warning' part the wrong way? Is there something wrong with the above?
Alternatively, is there something wrong with the way I am adding an image to the swallow below? The image (from file) will show up, but suddenly my warning part above shows too:
Evas_Object *img = elm_image_add(wid->edjeLayout);
if (img == NULL) {
dlog_print(DLOG_ERROR, LOG_TAG, "View: Failed to add a image.");
return;
}
// Create an image and set contents to imagefile
char *imageFileName = barcode_filename();
bool isSet = elm_image_file_set(img, imageFileName, NULL);
dlog_print((isSet?DLOG_INFO:DLOG_ERROR), LOG_TAG, "View: %s file [%s] to image",(isSet==EINA_TRUE?"Set":"Failed to set"),imageFileName);
free(imageFileName);
evas_object_show(img);
// Assign the image to the swallow2 part
elm_object_part_content_set(wid->edjeLayout,"swallow2",img);
I tried adding the image to the 'window' instead of the 'layout' but that didn't seem to matter. (I've seen many contradictory examples so I don't know which is right)
I tried setting the image to the 'swallow2' part name many different ways (again, many contradictory ways show). Is this the problem?
Otherwise, can someone explain what is going wrong?
The image_NotSetYet is not an image object.
Evas_Object* image_NotSetYet = (Evas_Object *) edje_object_part_object_get(elm_layout_edje_get(wid->edjeLayout), "warning");
That refers to the "warning" swallow part object.
You should never modify the state of the returned object, because it's meant to be managed by Edje, solely.
If you want to get the image pointer from your layout as you expected, you could use following instead.
Evas_Object* image_NotSetYet = elm_object_part_content_get((wid->edjeLayout), "warning")
But as above link describes, the image object should be manged by Edje.
You might got the 2nd problem because it is managed by Edje. So please use edje_object_signal_emit to handle swallowed images.
I'm trying to capture data from a SysListView32 class (according to Spy++) from another application. Sending a LVM_GETITEMCOUNT message to this handle always returns the correct number of items. There is a child window which is SysHeader32 which presumably contains header titles.
When I try to send a LVM_GETITEMTEXT message to the target application, it crashes. The relevant code for this message is below:
LPTSTR lpText;
LVITEM* lvItem;
lvItem = new LVITEM;
lvItem->iSubItem = 0;
lvItem->cchTextMax = 255;
lvItem->pszText = lpText;
//SysListViewHandle is the HWND to the SysListView32 'content' window
SendMessage(SysListViewHandle, LVM_GETITEMTEXT, 1, (long)lvItem);
Each 'cell' in the list contains text no more than 50 characters, so the max text size should be fine.
The list structure which I wish to get the data from has 16 columns and a variable number of entries, more than 5, so the wParam should be fine. The styles this list use are WS_CHILDWINDOW, WS_VISIBLE, WS_TABSTOP, WS_HSCROLL, LVS_REPORT with extended styles of WS_EX_LEFT, WS_EX_LTRREADING, WS_EX_RIGHTSCROLLBAR, WS_EX_NOPARENTNOTIFY, WS_EX_CLIENTEDGE, LVS_GRIDLINES and LVS_FULLROWSELECT.
UISpy is able to probe this list and find the actual data within so I presumed it would be a walk in the park to get using messages, but this has proved not the case =/ any assistance would be greatly appreciated.
EDIT: Worth mentioning the error log on crashing is:
Unhandled exception at 0x77582b87 in applicationname.exe: 0xC0000005: Access violation writing location 0x01bc48b0.
Call stack location comctl32.dll
Disassembly:
77582B87 mov dword ptr [esi],1
Your problem is that since the list view exists in another process, the memory you allocate is not valid in that other process. I refer you to an article over at The Code Project which offers a solution.
What's more, you do not appear to have allocated any memory for lpText so it would fail in your own process.
INT GetTree (HWND hWnd, HTREEITEM hItem, HKEY *pRoot, TCHAR *pszKey,
INT nMax) {
TV_ITEM tvi;
TCHAR szName[256];
HTREEITEM hParent;
HWND hwndTV = GetDlgItem (hWnd, ID_TREEV);
memset (&tvi, 0, sizeof (tvi));
hParent = TreeView_GetParent (hwndTV, hItem);
if (hParent) {
// Get the parent of the parent of the...
GetTree (hWnd, hParent, pRoot, pszKey, nMax);
// Get the name of the item.
tvi.mask = TVIF_TEXT;
tvi.hItem = hItem;
tvi.pszText = szName;
tvi.cchTextMax = dim(szName);
TreeView_GetItem (hwndTV, &tvi); //send the TVM_GETITEM message?
lstrcat (pszKey, TEXT ("\\"));
lstrcat (pszKey, szName);
} else {
*pszKey = TEXT ('\0');
szName[0] = TEXT ('\0');
// Get the name of the item.
tvi.mask = TVIF_TEXT | TVIF_PARAM;
tvi.hItem = hItem;
tvi.pszText = szName;
tvi.cchTextMax = dim(szName);
if (TreeView_GetItem (hwndTV, &tvi))
//*pRoot = (HTREEITEM)tvi.lParam; //original
hItem = (HTREEITEM)tvi.lParam;
else {
INT rc = GetLastError();
}
}
return 0;
}
The block of code that begins with the comment "Get the name of the item" does not make sense to me. If you are getting the listview item why does the code set the parameters of the item being retrieved? If you already had the values there would be no need to retrieve them.
Secondly near the comment "original" is the original line of code which will compile with a warning under embedded visual c++ 4.0, but if you copy the exact same code into visual studio 2008 it will not compile. Since I did not write any of this code, and am trying to learn, is it possible the original author made a mistake on this line? The *pRoot should point to HKEY type yet he is casting to an HTREEITEM type which should never work since the data types don't match?
The block of code that begins with the comment "Get the name of the item" does not make sense to me. If you are getting the listview item why does the code set the parameters of the item being retrieved, because if you already had the values there would be no need to retrieve them.
After that comment, the first line is to specify to TreeView_GetItem (which, by the way, is actually a SendMessage in disguise) that we want to retrieve the text of the item and the associated lParam. The next line specifies the handle to the item about which we want information.
The following line specifies where the retrieved text must be saved, i.e. in the szName buffer, which has been allocated at the beginning of the function; the last line before the function call specifies the size of such buffer, so to avoid buffer overflows.
I suggest you to have a look at the documentation of TreeView_GetItem and of TVITEM to understand better what's going on.
Secondly near the comment "original" is the original line of code which will compile with a varning under embedded visual c++, but if you copy the exact same code into visual studio 2008 it will not compile. Since I did not write any of this code and am trying to learn is it possible the original author made a mistake on this line, since the *pRoot should point to and HKEY type yet he is casting to an HTREEITEM type which should never work since the data types don't match?
It's not clear what the code is trying to do there; at first glance I'd say that in the lParam associated to each item in the root node of the treeview is stored a handle to a registry key, and the procedure retrieves it in that way. Still, if it was like that, the (HTREEITEM) cast wouldn't make sense at all; probably it was a mistake, forgiven by the compiler because it treated all handles as plain void *; if my hypothesis is correct you should keep the original line, just replacing (HTREEITEM) with (HKEY).
Many times, API calls take in information in a structure, and also return information in the same structure. If you look at the documentation for TreeView_GetItem, it will clearly show how it operates.
As for the second question, are you compiling as C++? What is the error?
The LPTVITEM parameter to the TreeView_GetItem macro is used bi-directionally.
TreeView_GetItem does indeed send the TVM_GETITEM message to the treeview. What's going on here is that the caller fills in a little bit of the struct to say "here's what I have and what I want" and then the treeview will fill in the requested bits.
From the TreeView_GetItem documentation
When the TVM_GETITEM message is sent, the hItem member of the TVITEM or TVITEMEX structure identifies the item to retrieve information about, and the mask member specifies the attributes to retrieve.
For the second part, I think it looks like it was a mistake, based on the names of the variables etc., but you should probably check how the function is used in the rest of the code to make sure.
The first question is pretty simple: you're filling in a few of the items in the structure to tell what data you want, then calling TreeView_GetItem to actually retrieve the specified data. In this case, you're specifying TVIF_TEXT, which says you want the text for the particular item. You also give it a buffer where it's going to put the text (szName), and tell it how long that buffer is (so it won't write past the end of the buffer). When you call TreeView_GetIem, it copies the text for that item into your buffer.
As to your second question: it looks like all that code (both old and new) is somewhat problematic. The general intent seems to be to retrieve the path to the item that was originally passed in, but it seems to do that rather poorly. It starts by recursively walking up the tree to the root. Then it retrieves the text for the root item, but only into the local variable szName -- which it then ignores (does not copy into szKey). It does store the handle to the root item into hItem (this is where it originally wrote to pRoot).
Then, as it returns (walking back "down" the tree), it retrieves the text for each item, and appends those names to szKey (separated by '\'), to form (most of) the path to the item originally passed in. Unfortunately, as it does this, it ignores the nMax that was passed in, so it can (apparently) write past the end of the szKey buffer.
Greetings,
I have a problem with printing in WPF.
I am creating a flow document and add some controls to that flow document.
Print Preview works ok and i have no problem with printing from a print preview window.
The problem exists when I print directly to the printer without a print preview. But what is more surprisingly - when I use XPS Document Writer as a printer
everyting is ok, when i use some physical printer, some controls on my flow document are not displayed.
Thanks in advance
Important thing to note : You can use XpsDocumentWriter even when printing directly to a physical printer. Don't make the mistake I did of avoiding it just because you're not creating an .xps file!
Anyway - I had this same problem, and none of the DoEvents() hacks seemed to work. I also wasn't particularly happy about having to use them in the first place. In my situation some of the databound controls printed fine, but some others (nested UserControls) didnt. It was as if only one 'level' was being databound and the rest wouldn't bind even with a 'DoEvents()' hack.
The solution was simple though. Use XpsDocumentWriter like this. it will open a dialog where you can choose whichever installed physical printer you want.
// 8.5 x 11 paper
Size sz = new Size(96 * 8.5, 96 * 11);
// create your visual (this is a WPF UserControl)
var template = new PackingSlipTemplate()
{
DataContext = new PackingSlipViewModel(order)
};
// arrange
template.Measure(sz);
template.Arrange(new Rect(sz));
template.UpdateLayout();
// print to XpsDocumentWriter
// this will open a dialog and you can print to any installed printer
// not just a 'virtual' .xps file
PrintDocumentImageableArea area = null;
XpsDocumentWriter xps = PrintQueue.CreateXpsDocumentWriter(ref area,);
xps.Write(template);
I found the OReilly book on 'Programming WPF' quite useful with its chapter on Printing - found through Google Books.
If you don't want a print dialog to appear, but want to print directly to the default printer you can do the following. (For me the application is to print packing slips in a warehouse environment - and I don't want a dialog popping up every time).
var template = new PackingSlipTemplate()
{
DataContext = new PackingSlipViewModel(orders.Single())
};
// arrange
template.Measure(sz);
template.Arrange(new Rect(sz));
template.UpdateLayout();
LocalPrintServer localPrintServer = new LocalPrintServer();
var defaultPrintQueue = localPrintServer.DefaultPrintQueue;
XpsDocumentWriter xps = PrintQueue.CreateXpsDocumentWriter(defaultPrintQueue);
xps.Write(template, defaultPrinter.DefaultPrintTicket);
XPS Document can be printed without a problem
i have noticed one thing:
tip: the controls that are not displayed are the controls I am binding some data, so the conclusion is that the binding doesn't work. Can it be the case that binding is not executing before sending the document to the printer?
I am attempting to get the X Window at a certain location on screen. When I asked people for a function to do this, they said you would just call XQueryTree recursively.
This is the code snippet which I think is somehow wrong. When I debug it, it seems to work perfectly. The only problem is that the output it gives seems a little strange. When I do XQueryTree on the root window, I get hundreds of children, when I only have five or so open. Also, it seems to think that there is a top-level window somewhere where there simply isn't one, and returns it as a result. No matter how I move my actual windows around, XQueryTree seems to indicate that there is another window on top of my windows (not covering the entire screen.) When I look at where it says the window is, it is at some arbitrary point on my desktop.
If this is of any help:
The display is from XOpenDisplay(NULL), and the root window I originally pass it is XDefaultRootWindow(display). I am running gnome under debian with metacity.
point getwindowatloc(Display * display, Window root, jint x, jint y) {
Window returnedroot;
Window returnedparent;
Window * children;
unsigned int numchildren;
XQueryTree(display,root,&returnedroot,&returnedparent,&children, &numchildren);
XWindowAttributes w;
int i;
for(i=numchildren-1; i>=0; i--) {
XGetWindowAttributes(display,children[i],&w);
if(x>=w.x && x<=w.x+w.width && y>=w.y && y <= w.y+w.height) {
point result={w.x,w.y};
XFree(children);
return result;
} else {
point result=getwindowatloc(display,children[i],x-w.x,y-w.y);
if(result.x!=INT_MAX) {
result.x+=w.x;
result.y+=w.y;
XFree(children);
return result;
}
}
}
if(children) {
XFree(children);
}
return notfound;
}
Thanks!
EDIT: For anyone who is searching for similar information: I ended up looking into the source of xwininfo. The key function is Find_Client in dsimple.c, which somehow ignores window managers to get the window you are actually looking for. If you want to look into subwindows, this is some code I added to Select_Window in dsimple.c which will recursively look inside subwindows, using XTranslateCoordinates.
Window child;
do {
XTranslateCoordinates(dpy,target_temp,target_win,x,y,&x,&y,&child);
target_temp=target_win;
target_win=child;
} while(target_win);
return target_temp;
I think what you want to do is query the root window's _NET_CLIENT_LIST property. This will produce a list of Window IDs for all client windows, excluding all of the "virtual" windows created by the window manager. Most window managers apparently support _NET_CLIENT_LIST, but you can also query whether or not any given feature is supported.
Your code looks right (I haven't tested it), and the results you describe don't seem strange at all. Metacity (and other X window managers) will create lots of windows around and near the application-owned windows to show the window title, borders and other decorations.
Try running your test with some simpler window manager like TVM (or even none at all). TVM should create a lot less windows than current window managers. This should make things easier to understand.
Usually, however, it's a bad idea to fight against the window manager. Can't you solve your problem in a higher level way withour having to use xlib directly?