In my project I have the need to create a Form with 16 identical replicas of the same controls. So far I've managed to do this by just copying and pasting the controls and renaming them one by one, however this is becoming really inefficient and I feel like there must be a better method to handle this situation.
Down below there is an example of what I'm talking about: every line has the same controls that are handled exactly the same, have the same Items and only interact with each other within the same line.
Is there a way to create a modular group of controls that I can replicate and handle with a simple incremental index? The best would be if modifiying the original one would affect every copy of it!
I'm using Visual Studio Express 2013 for Windows Desktop and C# as programming language.
This kind of data calls for a DataGridView Control. It supports text, checkbox and combobox "out of the box", and you can add support for Numeric Up/Down Cell as described here: https://msdn.microsoft.com/en-us/library/aa730881%28v=vs.80%29.aspx
Creating a custom control as Johnny Mopp suggested (in the comments) was the best solution for my problem.
Related
I have developed a windows form project using Telerik controls. Now for some reason I've to switch to Syncfusion controls. What is the best way to switch to new controls? Do I have to drag and drop all the stuff again..?? Or is there a any other option which may be less time consuming.
It's very time consuming. It's not only a matter to change the controls. Probably they are totally different in terms of events, costants and worse in terms of functionality. You will need to test all of your code and probably rewrite the UI interaction methods.
If you really need to do that, take your time, and use a version control system to create a branch for the new version while maintaining support for the old version still using the Telerik controls
You could just change the references in your *.Designer.cs files, but you'll probably run into errors when the Designer file attempts to assign properties that have existed in the Telerik controls and don't exist in the Syncfusion ones.
This approach will probably be less work than remaking every form, but it'll still take some time.
Windows Form (in C#) - I need to create a custom listbox control for the following requirement:
There is a listbox with a long list of items. I want the user to be able to click in the list, and then start typing and have it automatically take them to the matching item (I call this "type ahead"). It needs to be able to do this for as many characters as they type that have a match.
This control should be really reusable without much changes.
What are things/points I should keep in mind while developing a reusable custom control? (if you provide a good pattern as a sample... will be more helpful)
In Real World scenario the first decision should be buy vs build. if your application is a serious one and not just for hobby and there is budget for it I would check some of those great controls collections like DevExpress or Telerik for WinForms. You would need a grid as well at some point, eventually, and surely your custom or framework one cannot compete theirs.
I refer to those libraries because i believe they already have a listbox with autocomplete as you described in your requirements. check the online demos on their websites...
I'm newbie for Windows phone 7 development.
Usually the User interface Design is done with a Designer and Drag & Drop. But In my project I have to code all user interface programmatically, that is manually write design controls in .Cs file instead of .xaml file.
Is it possible? I have tried googling it, I haven't found any tutorial or documentation yet.
Could someone please help me to start my process.refer some documentation or books
Thanks
I definitely think you can do everything without XAML if you want to.
The basic approach should be to create a basic app with App.xaml and an almost empty Page.xaml. After this you should be able to dynamically add controls to meet your needs.
The majority of this work is quite straight-forward
creating controls, setting properties, adding event handlers are all easy.
The more awkward things will be things like producing animations, visual states, styles and databindings - the XAML syntax for these is quite convenient compared to the C#
Also, if you need multiple pages, then using navigation is also a bit more awkward - the NavigationService is currently built around XAML-based pages.
In iron7, I've written lots of single page apps without using XAML. All the code is in IronRuby rather than C#. As a developer, I think you should be able to follow most of them - take a look at these examples on script.iron7.com:
create a UI with some text boxes and some buttons
a calculator with animations
fingerpaint - canvas and "mouse" touch
panorama control and pivot control
Tetris
To run these scripts just download iron7free from the marketplace. To convert them back into C# is mainly a case of removing some "_" characters, modifying some capitalization and turning def's into C# methods.
Note - for clarification, I am not recommending you write your app in Ruby - it's just that these are the only examples I have of writing an app in code instead of XAML.
You have to create a basic xaml page first with at least a stack panel on it.
Then you can add controls to your stack panel like this
TextBox textbox = new Textbox();
textbox.Text = "TEST";
PageStackPanel.Children.Add(textBox);
You do have drag and drop ability for the Windows Phone 7 development. Download the Visual Studio for Windows Phone 7 and try the samples. http://www.microsoft.com/express/Phone/
Here is a tutorial for the starters:
http://blogs.msdn.com/b/somasegar/archive/2010/03/15/introducing-windows-phone-7-development-tools.aspx
Well its the Silverlight framework. You can code it by hand using XAML (eXtensible Application Markup Language)
Charles Petzold is writing a book on Windows Phone 7 programming, you can download it free here:
http://www.charlespetzold.com/
Generally I don't like the designer and try to avoid it as much as possible. I find writing Xaml easier.
But I also try to avoid the use of Xaml because:
Performance: the C# code is definitely faster
Programming style: I hate when the related code is scattered over several files. It's not only my C# code, but also hidden auto-generated code (sometimes containing unnecessary constructs).
Debugging: Xaml allows for more bugs (e.g. incorrect spelling), Xaml bugs are more difficult to localize
Having said that, I have to disagree with Stuart: Certain things cannot be done in C#, you need to do them in Xaml. For example:
Visual states: You cannot set readonly property VisualStateGroup.Name in C#, but you can use x:Name attribute in Xaml.
UserControl.Content is protected (for SVL3 and thus also for WP7), but Xaml bypasses this limitation
Etc. (There are more such special things.)
I've been out of doing proper programming for sometime, so as an exercise in trying to get some practice, I'm trying to make a program to solve Sudoku in C# (VS 2010)
My problem occurs when I'm trying to create some form of initial grid for the data out of text boxes. Back when I used to use VB6, I could call all text boxes as a single name and then give them all an index number which would allow me to refer to a specific text box when I was in a loop.
As far as I can see, there's no easily visible equivalent in C# and my searching has been to no avail although I can't imagine it'd be a feature that would be removed.
Thanks in advance
You can create a control array.
http://www.devasp.net/net/articles/display/674.html
It would probably be easier, and look better, if you use a genuine grid control like the DataGridView.
One bit of bad news. In the days of VB4,5,6 Microsoft used to release a new grid control with every version of Visual Basic, which was annoying (unless you rewrote your code every year). Well, they are still at it.
My workshop has recently switched to Subversion from SourceSafe, freeing us from automatic locks. This led to concurrent editing of the Forms, which is wonderful. But when multiple developers commit their changes, the code files created by the designer (all the files named TheFormName.designer.cs) cause conflicts which are very difficult to resolve.
As far as I can tell, this is because the code generated by the designer is heavily re-arranged whenever the user modifies it, no matter how little the actual change really did.
How do I make these conflicts easier to resolve?
Is there some way to tell the designer to modify the code less?
How do you, the experienced C# teams, deal with concurrent modification of a Form?
Here are some things to try:
Make things more modular. Use components like User Controls etc. to split forms into multiple, smaller physical files.
Use presentation layer design patterns like MVP to move code out of views and into standard POCO classes.
Recent versions of SVN allow you to take hard locks - use this to avoid complex merge scenarios.
Hope that helps.
I'm pretty sure there is no silver bullet for this problem as the designer stomps all over the designer.cs.
All I can suggest is to minimise the use of the designer. Personally I only hook to events in code and only use the designer only for initialisation and positioning. As such it isn't too hard to fathom differences in a changeset ("oh, someone has added a button", "oh, someone has changed how it looks slightly").
Yep, Designer's random rearranging sure is irritating. Does Microsoft use their own tools? Does Microsoft look at what they check into version-control? It boggles the mind.
Our team's "solution" is to hand-edit the Designer files after we're done editing them, to put things back to where they were, so that the text-based diff is readable, and so concurrent changes can be merged sanely. Luckily, most of Visual Studio's rearranging is simple-minded, so this works.
Sadly, we've found that this step is necessary to verify correctness -- we've found cases where Designer silently removes things that are needed, leading to broken code. So this step has to be done in order to work around whatever data-destroying bugs lurk inside. Sigh.
Since Microsoft has a poor track record of fixing its bugs, the only solution may be to improve Mono's WinForms Designer so that it's ready for prime time.
I'm not familiar with C# or the Windows Form Designer, but looking at some designer.cs files I could find online they don't have a particularly complicated structure.
What parts of it are being re-arranged? I guess it's mostly the order of the properties in the InitializeComponent() method that's jumbled up?
If that's the case, you might be able to write a simple script that re-orders those lines alphabetically, say (especially if you never edit these files manually anyway), and use that as a pre-commit hook script in Subversion.
Um, right... scratch that. The big red box at the bottom of that section says you're not supposed to modify transactions in hook scripts. But you might be able to find another way to run that script somewhere between the designer.cs file being changed and it being committed.
Edit:
Actually, given scraimer's comment on this:
Total hack, but in the worst case, just before a merge, I could sort BOTH files, and make the merge simply a line-by-line affair...
Can't you let Subversion set an external merge program? I've been using KDiff3, which can run a preprocessor command before doing diffs or merges, so you could automate that process.
It's true that the designer sometimes messes up the order of the controls in the code, which causes the file to look very different compared to a previous version. This indeed is a problem if the file is under version control.
However, I found that the designer works quite reliably even in very large forms and user-controls if you follow some rules, and in those rare case where it does not, I have a easy way to force the designer into arranging the controls in the "correct" order again.
My rules:
The comment at the top of InitializeComponent() in every .designer.cs says: do not modify the contents of this method with the code editor. Well, if you know what you're doing, then it's absolutely no problem to edit this file manually, because this is what you need to do. Just make sure you have a backup.
Typically, when you create a form or UC, you add some controls here and there and move them around until you find a nice arrangement. But in the .designer.cs file, the controls are ordered by the order of their creation, and not by your logic how they belong together.
After finishing the creation of the form or UC, I reorder both the declarations (at the bottom of the file) and instantiations of the controls and their adding to the respective parent control (both in InitializeComponent()) until they are in the order that I want them to have. This makes it much easier to find them if you have to change a property of a control in the code.
And it also makes it easier for version control, because you may easily see what part of your form or UC was changed just by seeing the place (rather towards top or bottom of the file?) of the change in a file comparison view.
But changing the order in these 2 sections does not automatically change the order of all the parametrization code that comes after the instantiation part in InitializeComponent(). This will be done when you execute the solution to the OP's problem, which is described next.
If you work with rule #2, then you need to do the same finishing work that you need to do when you encounter the problem that the OP describes:
You have to force the designer to arrange controls in the order that they have in the declaration and instantiation.
This can be done in a quite simple way (which worked for me in 99% of the cases so far):
Save all files of the form or UC
open the designer view
move one of the controls (e.g. by selecting it and hitting 1x left arrow key)
optional: look at the .designer.cs file and/or save the form or UC
move the control back to have your intended design (e.g. by hitting 1x right arrow key)
save the form or UC
The designer will rewrite the whole .designer.cs file and your controls should now be in the "correct" order.
There are rare cases where this does not help. These include DataGridViewRows in embedded DataGridViews and embedded UserControls. In these cases I additionally do similar finishing work which includes adding and removing a button:
Save all files of the form or UC
open the designer view
add a button anywhere in the form or UC
optional: look at the .designer.cs file and/or save the form or UC
remove this button again
save the form or UC
The only way I know of to truely avoid this problem when using a merge style source control system such as subversion is to hand code the forms and not use the designer. Obviously, this would not be good because hand coding these forms can take a while.
The reason this happens is because the control properties are serialized by the designer in the order they are dropped on the form. Cutting and pasting can effect this order as well as moving a control so that it has a new parent (such as moving a control on to a panel when it was previously directly on the form).
I had this problem on a large project and had to imploy a rather ugly approach - diff the designer.cs files against the check-in target revision and manually merge them using a merge tool. This isn't ideal, but it is the only way I see this working consistently with svn or another merge style source control tool.
The other option would be to use a lock approach with source control, as others have pointed out, but this comes with unpleasant side effects as well.