We have an MFC application that uses the CHeaderCtrl and have been using the HDS_FILTERBAR style to filter data. Works great. But our users want to be able to paste in text into the filter cell. I have not found a way to get a pointer to any CEdit-type of control here so that I can call >Paste. I have managed to detect a Control-V while in the filter in the application's ::PreTranslateMessage. There is a way to send text to the filter by way of a CHeaderCtrl->SetItem call, but this will immediately launch the filter. I just want to be able to paste text.
So...I tried (I was desperate) using keybd_event and SendInput to force keystrokes. This worked but had undesirable side effects, probably due to MFC's message handling, and in my case, the user already had the Control + V pressed down. But in just sending the letter 'A', and forcing the SHIFT key, I accidently discovered that the CHeaderCtrl's filter does support a paste if you:
CONTROL + SHIFT + V
The problem is its hard to do, and hard to tell my users to do this.
I can simulate this sequence using keybd_event, but again, its real quirky.
Can anyone find a way to either get access to the CEdit (if there even is one) to a filtered CHeaderCtrl or know of another workaround ? I tried using a spy utility, but was not sure what to look for. Sorry for the long post.
So remove Ctrl+V from the accelerator list and you can handle it inside the control...
(Answer added according to the comment).
Related
I have a CListCtrl in Report view, and I noticed that I can search by typing the first few letters of an item (the control selects the first item that matches as I type), and that this search "resets" after a second or so (so if I've typed "abc", pause, then type "d", then it searches for "d" only). For usability, I want the user to realize that this search-by-typing feature exists.
So here are the options I can think of, in order of preference, and the question I have in each case:
Use whatever existing built-in support there is in MFC.
Is there such a thing?
Some other solution that's been implemented before.
Again, is there such a thing?
Add another textbox to the dialog box, and handle its ON_EN_CHANGE message to somehow trigger CListCtrl's search behavior. In other words, similar to the find dialog/toolbar in browsers.
How do I trigger the search behavior?
Did take a look into the List-View controls documentation on Microsoft Docs.
This behavior is described in the Default List-View Message Processing (WM_CHAR message). The search-string is indeed reset after one second.
However, I didn't find any notification message that seems to be relative, eg returning the current search-string, which you can display. There is the
LVN_INCREMENTALSEARCH, but the documentation is rather confusing (eg what is an "incremental search"? etc), and I don't know if you are going to receive this at all, as this seems to be about Virtual List-View controls. Anyway, you can give it a try.
But resetting the test entered by the user in just 1 sec may rather be unwelcome to users or reviewers (actually I have never seen an application doing so). So you can implement some "Search" operation in your dialog, as you said add an edit box and search for its content. You can use the LVM_FINDITEM message (or the ListView_FindItem() macro) requesting a partial-match search (LVFI_PARTIAL), or do the search yourself (find the matching item and move there).
So im building a basic win32 GUI app and I have a vector of data that gets constantly updated through an external source via a port. Im interested in displaying that list of data to the user but im not sure the best approach to go about it without causing update flickering.
I originally had an edit box in which I build a string with the information and update the window. But it has proved troublesome as the amount of data grows since I cant scroll down to look at additional data. Any ideas?
My idea is no point of updating the visual control as the same speed you receive the data. Because even-though you update at the same speed the users cannot see that change at the speed of data receiving. Human eye does not see a change happening in speed as 1/8th of a second. So better to update the visual control in a controlled manner. Maybe using a timer.
Appending to the text of an edit control for each subsequent data point will lead to flickering as the whole control re-renders as the text has changed.
I'd advise one of the following options:
1) use a ListBox or ListView control; when you add another row item, it only re-draws the new/changed/scrolled item. https://learn.microsoft.com/en-us/windows/desktop/controls/create-a-simple-list-box and https://learn.microsoft.com/en-us/windows/desktop/controls/list-view-controls-overview
2) If you only want an always-scrolling list of data, consider just having a command-line application that writes to the standard output and saves you a lot of trouble - cout or printf your data.
You can also use EM_SETSEL and EM_SCROLLCARET to automatically scroll, but also check the position of the scroll bar before doing that. If not at the bottom, it means that the user wanted to pause, so you can scroll.
Also, you can have the scroll lock key checked in order whether to scroll or not, after all that is what it's name is supposed to do.
INTRODUCTION AND RELEVANT INFORMATION:
I am maintaining an old application and I need to implement feature that generates reports based on data calculated from a database. User must also have an additional option of printing the file ( user must be able to choose printer, and must be able to see print preview ).
To improve my chances of getting satisfactory answer, allow me to additionally clarify matters with a small "example":
User presses a button -> application calculates data; // Done
Application creates file and populates it with the result; // Done
User gets informed that report is generated; // Done
User presses another button that is charged for printing; // Stuck here!
Print preview pops up and an option to run print dialog. // Stuck here
User starts the print dialog, chooses the printer and application prints the file;
The application is coded in C++ using raw WinAPI ( no MFC ). I am working on Windows XP.
PROBLEM:
I was able to successfully use OLE Automation to generate/save Word and Excel reports but I can not create print preview that matches exactly the print preview Word would create.
If I use OLE Automation to show Excel's print dialog/print preview, there is a following problem that might occur :
User can simply click "Close Print Preview", or can simply close print property sheet ( please see picture below ) and return to the document which might compromise document's data.
My employers do not like this ( they have no software engineering / developing background, so no matter what I say it will end up as an "echo in the wind"... ) and they wish that my print preview matches exactly the print preview Word generates.
Therefore, I need a solution for generating a print preview for the user, in a way that matches exactly print preview Word would create. Furthermore, user should be able only to see how this looks like, but not to be able to open the file from my application. User should be able to choose the printer that will print the file.
An implementation similar to the one from the picture would be fine.
QUESTION:
INTRODUCTORY NOTES:
The question is too broad to be answered in one post so I must limit myself only for seeking advice / general concept / pointing in the right direction.
THE ACTUAL QUESTIONS :
I did the best I could with the OLE Automation and Excel / Word files, but as you can see there are problems with generating a print preview, hence the following questions :
Since this is my first time to tackle this kind of task, can you recommend me the proper way to handle it ( general concepts of course )?
Is there a chance that there is a workaround for my printing problem ( like sending WM_PRINTCLIENT message to the Word / Excel or something like that )?
REMARKS :
Again, I realize the question is too broad so just give me general concepts / pointers, so I could post separate questions if I get stuck somewhere in the way.
I do not need to use Word / Excel and OLE Automation, it was my choice at the moment.
If you can recommend better solution I will gladly accept. I do not wish to use libraries.
If additional information is required, ask and I will edit my post.
You would need to bring up a dialog box when the user clicks the print button, the dialog box would contain a control that shows the preview for the default printer and three buttons to select another printer, print and exit.
The preview control could be a static control where the WM_PAINT handler would draw the preview (alternatives: a Web Browser control which is fed html text or a RichText control which is fed RTF text, but then you are constrained by the functionality of these controls).
Quote: Print preview
isn't that special. It just means that you have to render to screen
(or bitmap) what you'd otherwise would render to the printer DC. This
primarly means using the page size, and providing a UI control for the
prev/next page.
This SO Answer describes in detail the work you need to do to paint the preview.
This CodeProject article has some simple code for print-preview; it's in simple MFC which should not be too difficult to translate to plain C++/WinAPI.
I've been following YouTube tutorials most of the day now and I think I've got the basic hang of forms. I'm aiming to create something like this below, which checks a users password and shows how strong it is:
This is what I have at the moment:
I'd like to know the basic theory behind how the top form works, specifically how I can take the user input of password in my form and just get it to print and update in realtime underneath below. I'm not quite sure what tool is used to do that, or for that matter what tool is used to create the colour changing box.
Any help or direction is appreciated, thanks!
Add a keyboardListener to your jtextfield. When a key is pressed get the text and do your stuff(figure out the strength, number of Uppercase etc)
Is this win32 or mfc forms, or some other tech like Qt or wxWidgets?
In both cases you will want to handle messages from the edit field as text is changed in it. This message is the EN_CHANGE message. Handle that message and you can get the text from the edit field and send messages to the strength form to tell it to change its color and text.
Add a System::Windows::Forms::KeyPressEventHandler (or similar) to the TextBox. When raised, do whatever analysis you need to do on the string and update the table below. The color changing box can be one of many implementations. It can be something as simple as a panel that changes its background with a System::Windows::Forms::Label positioned on top of it. It actually looks like that, as the text is not centered.
I've scanned through all pages in MSDN, but still not found asnwers of following.
Minimum Character Length of edit control.
Specifying range for input values in edit control.
Permitting only alphabets in edit control.
Setting tooltip for button control.
Please tell me how to do this in Win32.
This is hard to do properly. A naive approach would handle WM_KEYDOWN messages to intercept the backspace and delete keys (VK_BACK and VK_DELETE). However, you also need to handle a user selecting some of the existing text and then deleting it (via backspace or delete), cutting it, or replacing it (by typing a key or by pasting some other text). I don't think it's worthwhile, and even if you could do this well, it is likely to be confusing when you break all of those normal behaviors. (It also can be incredibly annoying. Imagine that you have some text "bar" in the control but you want to change it to "baz". If the control enforces a minimum length of 3, then attempting to backspace over the last character won't work. You would have to change it to "barz" first and before being able to delete the "r" character. Ugh.)
If your control needs a minimum length, you're better off enforcing it during a separate validation step (such as when the user clicks an OK button or moves focus to another control) and showing an appropriate error message.
I'm not sure whether you mean allowing only certain characters to be entered into an edit control or whether you want to restrict it to a range of numeric values. For the former, see 3.
If you want to restrict values to a certain numeric range, I again recommend doing it during a separate validation step instead. Otherwise you again might prevent the user from inserting and deleting characters in a normal way. If you can, avoid using using an Edit control and use a Trackbar (slider) control.
You would have to subclass the Edit control, handle WM_CHAR messages, and reject characters that you don't want. You additionally would need to handle WM_PASTE messages and perform similar validation.
This doesn't have anything to do with Edit controls and probably should be a separate question. What have you tried? Have you read http://msdn.microsoft.com/en-us/library/bb760250.aspx ?