I have a ribbon application that designed based on Extensible Application Markup Language (XAML) in c++. I want to change the icon of one button when i click on it.
How can i change the icon?
My application is not MFC, I use Windows API.
You can't change the icon of a button when clicking, at least not in a regular way. The API doesn't support this, I guess for the reason that the UI Ribbon UI concept doesn't intend such a behavior (and you may want to think twice, before breaking an "intended behavior").
Anyway, you could force such a behavior by loading a resource file that refers to the very same XML definition (XML by the way, NOT XAML - we are not in the WPF world here), with the only exception being the source path of the regarding icon referring to something different.
The relevant API call for this is called IUIFramework::LoadUI.
Related
I need to extend an existing MFC app with a UI that will end up very cluttered unless I use a tab control. However, the nature of the UI is that there are some controls that are global, and only some that can be localised to a particular tab.
The standard use of tab controls (CPropertySheet + CPropertyPage) more or less expects there only to be CPropertyPage instances (tabs) visible on the CPropertySheet object, and nothing else. There is a Microsoft Example Project that shows a single additional window painted outside the area occupied by the tab control... but it's not immediately clear how it is created/drawn/handled, and it is only one single additional window that generates few events (I guess it is painted, so there must be a WM_PAINT event handler lurking somewhere).
Is it possible to lay out a bunch of controls with the MS Dialog Editor, including a tab control, and create the CPropertySheet using that template, hook up event handlers in a nice way, etc... or some equivalent way of getting the MFC framework to do as much of the creating, drawing and event handling as possible when it comes to a situation like this?
Yes it is possible to create dialog templates and use them in a CPropertyPage.
Each CPropertyPage behaves nearly like a dialog and handles all events for the controls on it.
Also there are features like OnApply that help you to manage the data exchange between the controls and your internal storage.
The central CPropertySheet only creates the dialog that get active. So OnInintDialog for a page is called the first time when the page gets active.
In the MFC since 2010 are more possibilities than a CPropertySheet. You can create tabbed views, that again may be CFormViews. I don't like CDialog based applications so I would prefer a tabbed view in a standard frame with toolbar and menus if appropriate for the application. So another method to unclutter your UI is to choose the MDI interface with tabbed documents... but multiple documents maybe isn't what you want.
Here is a sample of an SDI application with multiple tabbed views.
Also Coeproject shows some more samples here and with splitters and tabs here.
There are at least three solutions paths:
Try to squeeze the situation into the CPropertySheet + CPropertyPage framework which does not naturally allow for additional dialog controls on the CPropertySheet object, and so you will get no framework support this
Place a tab control on an ordinary dialog, and then use the TCN_SELCHANGE messages to fire code that manually hides & shows individual dialog controls subject to the tab control (again no framework support, but this time "within" the tab control instead of outside it)
Follow Mark Ransom's observation that if you can embed one kind of CWnd-based control on a CPropertySheet then you can probably embed any such object, including a CDialog-based object that has been developed in the MFC Dialog Editor
All of these approaches are going to encounter challenges, and it will depend on the specifics of the situation as to which is better. But first you should really consider whether there is a cleaner UI design which would lend itself to a simpler solution.
In my specific case, I saw no cleaner design alternatives, and found it easiest to take the second approach. It left me with some reasonably simple calls to ShowWindow() to show/hide the controls inside the tab control.
I have an MFC app that uses AfxMessageBox to display message boxes. The app itself lets an end-user to change the user interface language. On the inside it does so by loading resources using LCIDs (or FindResourceEx API.) My issue is that I can't seem to make AfxMessageBox to take LCID to change the language for OK, Cancel buttons, etc. This also affects File and Folder Open dialog windows.
Any ideas how to do this?
PS. This approach must work under Windows XP and up.
According to this SO article, there are no standard functions for this, there's a link to a CodeProject article "Localizing System MessageBox" with source code for a DLL (it's in c# but seems simple enough to be rewritten in C++) which uses Windows Hook so that you can supply your own text for the MessageBox buttons; there's even a suggestion for sizing buttons to the text in the discussion part of the same article.
Office 2010 has a new type of ribbon, the backstage view. This has been implemented in MFC using Codejock Xtreme Toolkit Pro V15.0.1.
The thing is that I feel that the File>Open and File>SaveAs act very strange in Office. They open a modal file open dialog instead of opening an embedded file open dialog in the backstage, which would (IMHO) feel much more natural.
I cannot find a way of doing this in C++ using MFC or Win32. The only thing I found was this question, but that was for Delphi.
So, is it possible to embed the standard Windows File Open dialog as a control in another dialog? Or do I need to implement the entire thing myself?
To the best of my knowledge, The standard Open/Save dialog functionality is exposed through the modal dialog only (through the GetOpenFilename Win32 API).
There is a standard mechanisme to customise the dialog (See Skizz answer) but it remains a modal dialog. One case of advanced customisation was the VB6 Open Project dialog:
The Existing tab contains a file dialog. How did they do it? I mean, how did they manage to put a standard dialog into a page of their 3-tabs property sheet?
It appears that they simply used the standard customization dialog and added a tab control above the standard dir/file controls and listview for other 'tabs' above dir/file controls. These dir/file controls were then hidden by the custom code when a tab other than Existing was clicked. You get it: no real tabs! Just a good old file dialog where the main controls may be hidden in favor of other ones.
So my short answer is: You're pretty much out of luck using the dialog as a child control.
Now, to come back to Office: I believe it's better to keep a modal dialog. It would otherwise be confusing to user: Is the path that I started to type the real path of did I just clicked 'Home' and let the save command unfinished?
I don't know if you can embed a file open dialog into another dialog, but you can certainly extend the existing dialogs:-
Here's one implementation.
And another.
And an MSDN version.
Thanks to David for pointing out the above are a bit out of date, so, after a quick Google, here's a more modern take on extending the file dialogs (and lots of other stuff as well).
I am writing a C++ application and I have a Login Box that's shown in a regular Dialog Box Frame. I see that some people can SKIN the entire dialog box and makes it look really nice. I was wondering if anyone can give me some pointers as to how to do that.
I'd need more details to give you a good answer.
The answer very much depends on which OS you're using and how you're programming your GUI (for example on Windows - plain Win32, MFC, ATL, Qt, Windows Forms, WPF etc etc).
If you're just using the Windows API here's a link to get you started.
http://www.codeproject.com/KB/dialog/skinstyle.aspx
Beware: custom skinning dialog boxes can be a very large task if you want to customise the look of every control as you end up writing very complicated custom controls.
Alternatively do you just want to make sure that your dialogs appear with Windows XP visual style rather than pre-XP style? This will require changes to your application to use the new common controls and visual style. Note that this changes the behaviour of some Windows APIs and can potentially have side effects (see ISOLATION_AWARE_ENABLED).
I have an app with a customized frame (i.e., caption/titlebar, borders). I customized the frame by removing the WS_CAPTION style, and overriding OnNcCalcSize to reserve a custom-sized area for the caption, which the app paints in OnNcPaint.
A side effect is that the menu bar no longer displays, which is OK because I want to customize the appearance & location of the main menu. Unfortunately, I don't know how to do that. I would like the "File" menu to be further from the left edge than it is with the standard menu bar.
An acceptable alternative would be to remove the menu entirely, and use OnNcHitTest, OnNcPaint and OnNcMouseMove to manage a hand-coded replacement for the top-level menu.
I've never seen a way to modify the looks of the standard menu. You can remove it (remove the creation code from your InitInstance) and then code a replacement. I wouldn't do that in OnNcXXX though, rather make a new custom control that you position at the top. Or you could have a look at the MFC Next themed menus and write a custom UI renderer. It may be enough to override a few functions left and ride to set the alignment of the menu.
It's an MFC MDI app -- InitInstance is not where the menu is being created. I have tried to get rid of the menu (and succeeded, temporarily) but the MFC framework seems to be "putting it back" -- I think the MDI model has the child windows modify the menu, but the code that does that seems to be buried in the framework somewhere (or else I just haven't been able to find exactly where it happens in the application's code, but I suspect it's happening inside the MFC framework code). If I knew where, I might be able to override the methods(s) and take control... I think.
What would be the reason to write a custom control vs. handling OnNcMouseMove & OnNcLeftButtonDown, e.g.? I don't expect to need the functionality in any other app (a new app would be coded in C#, probably), so I'm looking for ease of implementation, not code reuse.