When you create an new VCL form with one and put one TEdit and one TComboBox in it windows text suggestions works only with TComboBox. I guess this is because the Edit part of the combobox is a windows edit. I cannot seem to find anywhere how to make the VCL's edit behave the same way. Is there some IME messages I need to handle in a certain way or anything else?
What you ask is usually named autocomepletion.
TEdit doesn't support this out of the box (Not that I am aware of).
But there are several solutions floating around on the internet.
Not a direct solution, but have look at the answers to this question and also this one.
There is source code available for several solutions, you'll find it with this search on Google.
I'm trying to hide a form from the menu using VBA; I've Googled this, but everything is giving me the .visible option, however I want to hide it from the groups menu located on the left side. I could just as easily manually do this, however it's very tedious and I can't be going on other user's computers to do so.
Is this possible?
I might suggest normally you should only disable menus vs. removing them all together, might suggest doing an enable/disable menu item instead..
It should be possible but how much work is it and is it worth it to you? It isn't clear what your host application is just that you're using VBA. Might suggest the host application may already allow for customization if so use what it provides.
If the app doesn't allow customizing your menu you can still do it, just how much work is it worth for you? You'll need to look at the Win32 way of doing things. If not familiar with Win32 and menus take a look and start here looking here at MSDN to start learning about menus in Windows. After this you'll find Pinvoke will be handle to give you C#/VB sample to call what is needed. The VB should be useful but you will probably need to further translate the VB to VBA for your needs. FYI when starting out a a C/C++ developer back in the day 30 years ago it was anticipated anyone getting into windows might take them a few months, there is a lot you'll need to get up to speed on. Thus is this feature really worth it?
My wife complains that I have too many icons on the Windows XP-Pro desktop.
I like to be able to quickly drop a file onto the icon for application I want to have open it. And I like to follow a link to open often-used deeply nested folders rather than navigate there. Thus, I have over 100 icons on the desktop.
(We share the same user account because we switch back and forth so often and because we both need to access the same e-mail, so separate accounts isn't the answer.)
I'd like to write a program which would have similar functionality to the Windows desktop. Then I could open that window to do the drag and drop work, but, when minimized, would leave the desktop display sparsely populated for my wife. As an added bonus, I could implement better organization of the icons than the desktop allows.
This is similar to what an Explorer window does, with the key exception that the desktop allows you to do some arrangement of icons. (For instance, program icons on the left (with the most used ones near the top), folders at the top, data files on the right.)
How do I go about getting an icon to display in a Windows Form (or on an appropriate control on the form)? (For instance, if I drop in a link to Notepad or a link to a file folder.)
How do I take the same action that the desktop does if the icon is double clicked? (For instance, if a link to a folder is double clicked.)
How do I take the same action that the desktop does if the icon has something dragged onto it? (For instance, a text file is dragged onto the Notepad icon.)
I'm using Visual Studio and C#.NET for programming.
I know how to do basic drag and drop.
I do not know:
A. what controls to use on the form to display the icons
B. how to find the icon
C. what commands are built by the desktop under various situations (so I can emulate the functionality)
I apologize that this is a multi-part question, but it was hard to break apart without explaining the whole story again.
This is a big question, but I'll give you some quick thoughts to get things moving in the right direction. WinForms exposes the functionality needed to make this happen, it's just a matter of wiring everything up the way you want it.
The key piece that you will want to look into is Drag/Drop, which is very well supported by WinForms. If you implement your icons as ImageBoxes you can set the AllowDrop property on the program icons and then handle the DragDrop event and have it call an overload of System.Diagnostics.Process() to start the application with the dropped filename as an argument.
As far as finding icons, most programs have their icon included as a resource in their .EXE file or in a related .DLL.
Regarding question C, the underlying question is what behaviors of the desktop would you like to have in your program? Explorer.exe is a massive application that does far more than what you need or what you will need or want to implement. Once you decide what functionality you want, play around with the IntelliSense list of events for the form and imagebox controls. You'll find that a lot of behavior is given to you for free in the Windows common controls, and additional behavior is fairly easy to add by handling the appropriate events.
Why dont you just use a Virtual Desktop??
Try http://virtuawin.sourceforge.net/
You will skip a lot of coding.
Right from their page:
"VirtuaWin is a virtual desktop manager for the Windows operating system (Win9x/ME/NT/Win2K/XP/Win2003/Vista). A virtual desktop manager lets you organize applications over several virtual desktops (also called 'workspaces'). Virtual desktops are very common in Unix/Linux, and once you get accustomed to using them, they become an essential part of a productive workflow."
In my VC++ application I have an embedded browser (MSHTML). It works fine and handles the mouse properly (for instance, clicks and selects are processed OK). However, mouse wheel rotations over the embedded browser do not have any effect. This is my problem.
I am not very familiar with the internals of MSHTML embedding, and OLE in general. This is an wxWidgets application (wxWidgets is a C++ GUI library), and I am making use of its IEHTMLWin component (which hosts an MSHTML control and wraps it in the wxWindow interface). However, I do have the source and am willing to do some debugging.
Forgetting wxWidgets and speaking purely about OLE and MSHTML, what's the right place to start looking for the problem cause? I tried naive googling for variants of "mshtml mouse events" or "mshtml wheel", but didn't give any good pointers.
Should you want to take a look at the code of IEHTMLWin, it can be browsed here. The iehtmlwin.c file (1,5 k lines) has all the OLE-related code and implements all interfaces needed to host a web browser control. It's worth noting that mouse events don't proceed to the containing wxWindow at all (OnMouse is never called).
{UPD} mshtml version: 6.00.2900.3314. Other applications that host this control (including IE) support the wheel. {/UPD}
jdigital hint (regarding winspector) was very helpful. After some message sniffing, I realize that the problem is focus-related. A click on the browser control somehow does not set focus on the browser control (unlike, say, RichEdit), and WM_MOUSEWHEEL is not sent there. So the new problem is setting the focus.
Try Winspector (http://www.windows-spy.com/) which will allow you to see the windows messages. Make sure that the scroll wheel events are getting passed through.
I have the in my opinion odd request to close a wizard form as Done or OK if Enter was pressed on the keyboard even if the OK/DONE button is not focused.
In my opinion that would be a usability mistake. For example: In the wizard you may have multiple controls, buttons, check boxes, multiple line controls and they all have a different behavior on actions from the ENTER key. And don't forget the other buttons in the navigation of the wizard, what if they are focused?
Should these controls don't react on Enter like expected before? Should they do their actions but in other cases where Enter does no further action for the control it should close the form == inconsistent?
I think that is a typical request where the needs of one person would help him but confuse many other.
In my opinion Wizards are very special because they are not only made to make things easier but also very often focus on people with less experience with the functionality of an application. So I take every request serious and try to look into all arguments for and against the request.
Is my point of view to narrow? Are there some usability studies or guidelines especially for Wizards to backup my opinion or maybe proof me wrong?
Thank you very much!
Michael
Well, here's the thing: there are two kinds of users you have to take into account here.
First kind of users are the Baby Boomers and Gen Xers (e.g., people who have been using computers in the 70s/80s) who are accustomed to pressing Enter to move to the next field. These are the ones who learned how to use computers in terminals/consoles and enter means you're finished typing on that field and would move on to the next.
Second kind of users are those who were weaned on Windows. These people are used to pressing the Tab key to move to the next field. Pressing enter to them means they are done with the whole thing.
So which convention should you follow? That will depend on whether you're targetting the first or second type of users, the environment (Windows or Web?), and the OS.
If you're targetting Windows forms, it is much advisable to be consistent to the OS (e.g., letting people use Tab instead of Enter) for form entry. In the web, you're in a quandary, since Enter is trapped by the web browser as a submit event.
In the end the only useful advice I can offer is to try it out with your target customers and see whether they prefer Enter over Tab.
I think the key is to test. You can't really guess what your users will find comfortable, you have to watch them try it. Especially since there are multiple incompatible standards you could follow, you are just going to have to see if this change works for most users in your audience.
I would be of the same opinion, perhaps mention it to the client and let them use the final version in both modes. I guess you have to give them what they ask for when they are paying.
To me this also seems to be an odd request but as Paul says, if the client wants it, then the client gets it.
However from a usability/comprehension standpoint, I would make the border of the ok/done button much thicker then normal so that it stands out a bit and maybe indicate to people that it has special behaviour.
Also I would perhaps make a note in the dialog/wizard box that hitting enter will cause the wizard to close as if the OK/Done button had been pressed.
While the one user may know that hitting enter will close it, unless someone else is specifically told, they will not be expecting that behaviour.
I think you should have a finish page to facilitate this. If the user presses enter by mistake the worst is that he won't finish the wizard, only go to the next page (which may be the finish page). This is good for situations where nuclear bombs are controlled by said wizards.
On the finish page pressing enter would finish the wizard (and blow up Iraq, bring down a satellite, or erase Jimbob's farm).
If the user can re-run the wizard I don't think it would be disasterous if they accidentally finished it.
Remember, wizards should never take any action until they are finished, in case the user cancels or such. Confirmation dialog boxes on a finish are tedious and I will hunt you down if you use them, I think once the user has finished the wizard he is pretty sure about his intent.
Maybe the client has good reasons for it.
Imagine the following situation:
A screen with lots of optional fields that gets opened/closed a lot and where data accuracy is not really critical.
Think of a little program that pops up every half hour to ask you what you have been doing, for what client and maybe some notes so it can gather this info and generate your timesheet.
Being able to open up the screen, enter the info and close it all really quick and with as little hassle as possible is way more important than the accuracy of the data.
I can imagine lots of situations where being able to confirm the field without having focus can be usefull.
Is this request perhaps because the UAT that was undertaken on the wizard involved users that weren't aware that pressing ENTER will have the same effect as clicking the button?
If when the final page of the wizard is displayed, the 'Finish' button is already highlighted (as I would expect) that maybe it's a matter of giving the user some cue that they can also press ENTER at this point.
If you take Google for example, I seem to remember that if you tend to systematically type your search term in and then click the 'Search' button with the mouse, a message is displayed at the top of the search results that kindly hints to you that you can also just press ENTER. Obviously, this is not something that can easily be done in your case because this is the last page of the wizard, but maybe this is the sort of thing that your client is trying to get you to engineer around?
Educate your clients. Show them some documentation as why that suggestion might not be a good usability practice.
Some reputable website will work best, as clients will usually believe a third party before believing you. After all, to them you are probably just being lazy and don't want to work more.
If the client still doesn't concede, then just do what they want, and warn them that it is not the good thing to do.
Although in your case, the "good thing to do" seems a little on the gray area.
I would argue that you could possibly use this functionality to move forward through the wizard but ONLY if no other action had been taken on that page.
The moment a field is completed or a button clicked/highlighted or the cursor is moved from the default position, the Enter functionality should revert to that of the standard OS.
As others have said, clearly this would only work if those using the wizard were made aware of this as part of their application training, but it might prove useful for moving quickly through un-used pages of the wizard to get to where the user needs to be.
Doesn't matter. Choose and be consistant in all your applications