So far, I've been able to create a window in C, and add a button and edit box to that window. But, where can I find an exhaustive list of the system classes for all the form controls? I can't remember where I found BUTTON and EDIT--is there a LABEL? LISTBOX? CHECKBOX? COMBOBOX? etc.
Then, how would I use those built in windows functions...I think they're called common controls? Like open a file, save as, print, etc.
You will go insane if you try to write raw Win32 code with C. If you can use C++, I highly suggest using Qt, if not, use Gtk.
Here you are: they are on MSDN.
But I agree with Zifre that you better use a gui-framework for stuff like this.
There are more like these, e.g. MFC or WTL.
Some people like things pure
stromcode zetcode forgers and heck if you're really feeling crazy, win32 in assembly
For the open dialogs and so on you want the Common Dialogs section -- http://msdn.microsoft.com/en-us/library/ms645524(VS.85).aspx.
Whilst on the subject of Win32, if you're using the file dialogs and therefore file names you may also find the shell functions (http://msdn.microsoft.com/en-us/library/bb776426(VS.85).aspx) handy -- in particular, the PathXXX ones. I wish I'd known about these when I was getting started.
Related
I am working on a C/GTK+3 project right now. I have a little experience with front end but mostly only with Android. Even then that was VERY LITTLE experience.
I notice that in the C code I place objects and set properties (like if a textview is editable etc). I also have been able to connect a .ui XML file to my program with the builder functions.
I am wondering how the XML file gets linked to the C code defining the interface. Does it match by structure, by the name or ID properties? Why are properties like "visible" and "editable" present in both the C code and the XML? Do you need the XML file? Do you need to specify the properties in both the XML file and the C code or just one? Will I ever completely understand front end development?
There's two ways of constructing a user interface:
You write the code for it.
You write a file that describes the user interface, and have the user interface built for you at runtime.
If you write the code yourself, everytime you want to move widgets around, you have to modify your code, that you'll need to compile. That is doable for a small UI, and is what is done in most tutorials.
If you use ui files, then you use the Glade application to design your UI graphically, and it will write the UI files for you. This helps in splitting responsabilities too: you may have design people taking care of the UI, and let developpers focus on the behavior. Even without that, you'll be able to design a UI faster with an editor like Glade than by coding it by hand. Think you skip all the compile/debug cycles.
In your ui file, if you name a wigdet "bob", you'll be able to get it in your code by passing its name to gtk_builder_get_object. GtkBuilder takes care of the construction and the memory, so don't destroy the widgets it creates if you need to display them again, and hide them instead.
You have examples of use of UI files in the GTK documentation:
https://developer.gnome.org/gtk3/stable/ch01s04.html#id-1.2.3.12.5
Basically, what do I have to do to Localize something like this:
MessageBox.Show("Hello");
So depending on the culture it should show "Ciao", "Hola", "Bonjour", but this has to be done in the code, can't move it to the GUI.
I know how to localize the GUI (with LocBaml), but that doesn't work with what I need, but I can imagine is something similar to what LocBaml does (expect the part where it generates an assembly maybe). I just need a pinpoint in the correct direction.
Thanks!
If your strings are already localized using resource dictionaries, you can use just
MessageBox.Show((string)Application.Current.Resources["IDS_HELLO"]);
This approach has however a small disadvantage that the text won't change automatically if the application's language is changed during the messagebox.Show. (Mind that the dynamic localization requires anyway additional effort from your side.)
I'm looking to add a 'close' button to my main window's menu. An example can be found in the picture here: http://ifyoucodeittheywill.com/img/crimson-editor.png
(So, there's the normal close button in the window caption area, but, there's also a close button in the window's menu bar -- on the far right).
I'm using basic win32 API's, though an example using MFC would also be fine.
Does anyone know how to do this?
Thanks,
Andrew
These buttons usually come with MDI windows. However I'm pretty sure the depicted application uses either its own, or more probably some advanced third party toolkit. Because, to be honest, what the Windows API and MFC (which is just a classed wrapper around the windows API) give you for GUI programming is unbareably limited.
If you want to design neat UIs steer clear from MFC and better have a look at something like Qt, wxWidgets or the like.
A really simple way of doing this is to use a regular menu item, using AppendMenu, but use the following flags:
MF_BITMAP with a close button bitmap, or MF_OWNERDRAW or to draw it yourself
MF_HELP (aka WM_RIGHTJUSTIFY), a not-very-well documented flag, which will justify the item to the right.
Here's one reference to MF_HELP that I found on msdn - it's actually about using the Win32 API to right-justify a menu item, but using Visual Basic.
MF_HELP (defined in winuser.h) is something of a holdover from Win16 days, back then, the convention was to right-justify the Help menu item, so it would stand apart. It was 'renamed' - an additional #define added with the same value - to WM_RIGHTJUSTIFY around Win95.
Note that bitmap menu items aren't accessible (eg. to users that are relying on a screenreader to read out where they are on the screen); if taking this approach, then at least add a regular 'Close' menu item elsewhere in the menus (eg. under File), so that a user doesn't have to rely on this item, and can also close it through usual means. Also be sure to implement the Ctrl-F4 shortcut, which is what most applications that support multiple documents or tabs use to close the current item.
By all means do not try to create this behaviour yourself. This is functionality that you get "for free" if you are using the MDI architecture of MFC. The close button "next to the menu" as you call it closes the active MDI child window. If you are not using the MDI architecture then there is no point in trying to add a close button there. Can you explain if you are using the MDI architecture?
I'm using Prism pop-up region and the popup is modaless. When I tried to change Prism sample codes to replace .Show() by .ShowDialog() command, the codes become unstable. So, I need to keep the current codes intact and think of a work-around: change to modaless mode to be modal mode.
I don't know how to do that and/or if that is possible or not. Please share if you know how to. Thank you!
If you are using the Stock Trader Reference Implementation and the RegionPopupBehavior and the DialogActivationBehavior then yes you can. You should only have to change the PrepareContentDialog method of the DialogActivation behavior method from Show() to ShowDialog().
The reference implementation example is not very robust, and I ran into problems creating a more robust popup with the sample code. However, once you tweak the behaviors, you can get it working well.
If you provide more details about your specific problem, I may be able to provide more help.
I have created a class that is simply THIS
Class UserControlBase
Inherits UserControl
End Class
Then I changed the Inherits clause in each of my UserControls designer file to
Inherits UserControlBase
I know that generally you shouldn't manually mod the designer file. But in cases like this what else can you do? Is this OK? Is there a best practice I don't know about? Is there some other way to accomplish the same end (extending UserControl) ?
I have not had issue changing the Inherits line, adding Namespacing, or adding Imports/Using statements. If you need to do any of these 3, you won't find many other ways to handle these requirements.
I change them all the time in my C# projects... often it's the easiest way to duplicate something that you've done once in the designer to a similar form and you want to do the same thing in a different form. Visual Studio is perfectly capable of reading in your changes and incorporating it into the designer. I really don't know why there is a comment saying not to edit it. My advice would be just make sure you use source control, go ahead and edit it, test it well, and if it works, great, if not you can always back out your edits.
No. It's never a good idea to modify a file that's generated.
The Designer files are pretty simple code; the only thing that you'll typically find in there to complicate matters (but only slightly) is BeginInit/EndInit calls at the top and bottom of the file--between those the code is pretty forgiving.
*That said, do not put any code in there that will only execute at Runtime. Any runtime-dependant code will fail at design-time, so trying to open your control in Design view will blow chunks. It used to give you the Red Screen of Darn, but I'm not sure what effect the IDE has notwadays--but if things blow up and the usual tricks fail to remedy them then try removing your customized sections.
Further on that note (not to scare you, but rather to hopefully head off some of the difficulties we had) the means of determining if your code is executing in Runtime or Designtime often fail if your code is not part of the currently built solution/project.
So to bring it all home, simple UI layout/winforms modifications are perfectly fine to do by hand in the designer code. Databinding and external dependencies (with the exception of calling third party control libraries) should be cautiously approached.