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
Well, I'm a newbie. I'd like to write an app in WPF. The main purpouse will be in drawing predefined elements/objects. Input from user is mostly realized by text boxes - numbers. But I'd like to add some kind of user input into drawing itself too + zooming and moving. Next functionality will be in saving the draw for later loading and another editing (printing maybe, but it's far far away).
I can imagine something like this:
due to some user interaction I'd prefere to use of InkCanvas
i want to define my own elements/objects with some properties. But where it will be define? Some external file maybe?
the save file will be composed of XAML code only
I will study this more lately, but I want to know if my thoughts are in the right way.
Are these points correct, or completely bullshit? :)
Thanks, and sorry for English...
I don't know if this is exactly what are you looking for, but here a little list of advice to help you on reaching your goal:
First of all, if you are crating an application, you should see this before. It explain the Model-View-ViewModel pattern, which is essential when you are creating something on WPF. This can help you abount your 2nd point.
Regarding your save file, i don't know exactly what you have in mind, but it depends on what do you want to save exactly. If you want, InkCanvas have the option to export directly the work in a bitmap . If you need to store some setting, depending on your need you can work with Settings or Resources
InkCanvas seems the appropriate tool for your need. Of course you will have to build your app around this control
Fairly new to WPF.
I'm tasked with converting our application with about ten different windows into a single-window, multi-tabbed application. I'd like your input on the most effective way of doing this.
I suppose I could do this the most-straightforward way -- copying and pasting a ton of code into the main XAML file. I imagine I'd end up with a gigantic file though, and would like to avoid that.
I should mention that the contents of each tab will be substantially different from each other.
There must be some element of WPF that enables this that I just haven't been able to find. Really appreciate any input.
In XAML there are user controls which you can use. That way, you could use one user-control per tab-content and let the main window only contain the tabview and tabitems and some minor logic code.
To achieve that, you can simply copy-paste most of your current window-code in one user control per window. The code base could remain almost the same (if there are no interactions between the windows at least).
There are quite many resources out there containing further details on user controls like this code-project article (a bit old, but the majority of its contents will still apply) or that MSDN one.
I'm in the process of writing a set of documents to help other developers in our office localize various components of a large application. I'm using a tool called Globalizer.NET to do the donkey work and it's very good as it even lets you localize the size and position properties of controls to allow for the likely changes in length of text strings once translated. However, it occurred to me that in some cases I might need to re-size the entire form a bit, but Globalizer doesn't let you do this, and I cannot see any other way of doing this. I have even tried manually adding an entry in the language specific resource file for the form size but it doesn't make any difference.
Ultimately, once it has become a little more established, we'd consider moving to WPF which I understand makes this easier, but for now we can't for a number of reasons.
Is there any way at all to localize this property of a winform? I am beginning to suspect not, but figured I'd ask in case someone else has come up with a workaround.
Don't worry - about a moment after posting this I had a bit of a Homer moment and realised I was trying to use the wrong property - ClientSize is a perfectly localizable property!
Thanks for reading.
Steve
Although Hungarian notation is considered bad practice nowadays, it is still quite common to encode the type in the name of user interface elements, either by using a prefix (lblTitle, txtFirstName, ...) or a suffix (TitleLabel, FirstNameTextBox, ...).
In my company, we also do this, since it makes code written by co-workers (or by yourself a long time ago) easier to read (in my experience). The argument usually raised against doing this -- you have to change the name of the variable if the type changes -- is not very strong, since changing the type of a UI element usually requires rewriting all parts of the code were it is referenced anyway.
So, I'm thinking about keeping this practice when starting with WPF development (hmmm... should we use the txt prefix for TextBlocks or TextBoxes?). Is there any big disadvantage that I have missed? This is your chance to say "Don't do this, because ...".
EDIT: I know that with databinding the need to name UI elements decreases. Nevertheless, it's necessary sometimes, e.g. when developing custom controls...
Personally, I find that WPF changes the rules when it comes to this. Often, you can get away with little or no code behind, so having the prefixes to distinguish names makes things more confusing instead of less confusing.
In Windows Forms, every control was referenced by name in code. With a large UI, the semi-hungarian notation was useful - it was easier to distinguish what you were working with.
In WPF, though, it's a rare control that needs a name. When you do have to access a control via code, it's often best to use attached properties or behaviors to do so, in which case you're never dealing with more than a single control. If you're working in the UserControl or Window code-behind, I'd just use "Title" and "Name" instead of "txtTitle", especially since now you'll probably only be dealing with a few, limited controls, instead of all of them.
Even custom controls shouldn't need names, in most cases. You'll want templated names following convention (ie: PART_Name), but not actual x:Name elements for your UIs...
In my experience - In WPF when you change the type of a control, you normally do not have to rewrite any code unless you did something wrong. In fact, most of the time you do not reference the controls in code. Yes, you end up doing it, but the majority of references to a UI element in WPF is by other elements in the same XAML.
And personally, I find "lblTitle, lblCompany, txtFirstName" harder to read than "Title". I don't have .intWidth and .intHeight (goodbye lpzstrName!). Why have .lblFirstName? I can understand TitleField or TitleInput or whatever a lot more as it's descriptive of the what, not the how.
For me, wishing to have that type of separation normally means my UI code is trying to do too much - of course it's dealing with a UI element, it's in the window code! If I'm not dealing with code around a UI element, why in the world would I be coding it here?
Even from a Winforms perspective I dislike semi-hungarian.
The biggest disadvantage in my opinion, and I've written a LOT of ui code is that hungarian makes bugs harder to spot. The compiler will generally pick it up if you try to change the checked property on a textbox, but it won't pick up something like:
lblSomeThing.Visible = someControlsVisible;
txtWhatThing.Visible = someControlsVisible;
pbSomeThing.Visible = someControlsVisible;
I find it MUCH easier to debug:
someThingLabel.Visible = someControlsVisible;
whatThingTextBox.Visible = someControlsVisible;
someThingPictureBox.Visible = someControlsVisible;
I also think it's far better to group an addCommentsButton with an addCommentsTextBox than to group a btnAddComments with a btnCloseWindow. When are you ever going to use the last two together?
As far as finding the control I want, I agree with Philip Rieck. I often want to deal with all the controls that relate to a particular logical concept (like title, or add comments). I pretty much never want to find just any or all text boxes that happens to be on this control.
It's possibly irrelevant in WPF, but I think hungarian should be avoided at all times.
I like using a convention (just a good idea in general), but for UI stuff I like it to have the type of the control at the front, followed by the descriptive name -- LabelSummary, TextSummary, CheckboxIsValid, etc.
It sounds minor, but the main reason for putting the type first is that they'll appear together in the Intellisense list -- all the labels together, checkboxes, and so on.
Agree with the other answers that it's mainly personal preference, and most important is just to be consistent.
On the need for naming at all, given the prevalence of data binding... one thing you might want to consider is if your UI is ever subjected to automated testing. Something like QTP finds the visual elements in an application by Name, and so an automation engineer writing test scripts will greatly appreciate when things like tabs, buttons etc. (any interactive control) are all well named.
In WPF you practically never need (or even want) to name your controls. So if you're using WPF best practices it won't matter what you would name your controls if you had a reason to name them.
On those rare occasions where you actually do want to give a control a name (for example for an ElementName= or TargetName= reference), I prefer to pick a name describing based on the purpose for the name, for example:
<Border x:Name="hilightArea" ...>
...
<DataTrigger>
...
<Setter TargetName="hilightArea" ...
I prefix any user-interface name with two underscores, as in __ so it is sorted before other properties when debugging. When I need to use IntelliSense to find a control, I just type __ and a list of controls displays. This continues the naming convention of prefixing a single underscore to module level variables, as in int _id;.
You can use the official Microsoft website for Visual Basic 6 control naming conventions, and perhaps combine it with the recommended C# naming conventions. It's very specific, is widely used by developers in C# as well for control names, and can still be used in a WPF or Windows Forms context.
Visual Basic 6 control naming conventions: Object Naming Conventions
C# recommended naming conventions in general: General Naming Conventions