|
hi,
i want to create a menustrip in right hand side like treeview.
i am using visual studio 2010, i drag and drop the menustrip, its automatically going upside of the window and i am check all properties there is no chance to display in right hand side...
i want to create like..
window have two sides ( left and right )
right side have the menu strip like treeview,that is have click event
and click the particular menu corresponding window shows the left side
Regards
Anand Rajan
|
|
|
|
|
look for the Dock property of the control or the HorizontalAlignment if you are using WPF
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
thanks
actually the sub menu are not visible that is inside id the menu...that is my problem i want show all sub menus with menu like tree view...
that is possible..
|
|
|
|
|
|
don't know how to do that by own code but i can tell that the devComponentsDotNetBar2 has such elements in it 
Maybe you check that out and give it a try
if(this.signature != "")
{
MessageBox.Show("This is my signature: " + Environment.NewLine + signature);
}
else
{
MessageBox.Show("404-Signature not found");
}
|
|
|
|
|
Hi all,
Am going to develop a website which has to handle different kind of users and there is an option to enter the different kind of data(real estate information). Each
real estate information can be considered as an object .Recently I read about design patterns. How to determine whether i need to use a design pattern or not in and which one I need .
Regards,
Jeena
|
|
|
|
|
Decide on the tech you want to use, find all the design patterns related to that tech, write all the name on a piece of paper and stick them in a bowl. Pick one!
I thought I had made the right decision moving to Silverlight and MVVM!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Design Patterns are like programming languages:
They don't solve your problem by themselves, neither they guaranty that your design decisions are an appropriate solution for the problem. Stick with a design pattern you like, and most important, understand.
Another fault that seems to happen very often is that people pick a design pattern and then later start to abandon it, and switch to another one - Which leads to crapcode and mass confusion, sooner or later.
I found a nice page summing up all of the important aspects of design patterns:
Patterns are not the panacea of program design. They do not replace traditional object-oriented analysis techniques like CRC cards or use-case modeling. To use an architectural analogy, analysis lets you determine that your house needs 200 amps of electricity. Patterns let you determine how the wiring will be installed.
Patterns do help you think about the problems you may encounter while designing a system. Therefore, a generic, pattern-based solution is often more robust than a solution designed by one individual to solve a specific problem.
Given the number of design patterns in common use (as well as many more being invented and discovered almost daily) it can sometimes be hard to choose the pattern that suits your needs.
The first thing you should decide is whether the problem is fundamentally creational, structural, or behavioral. Some problems, of course, have aspects of two or even three, and may require you to mix and match patterns.
Veni, vidi, caecus
|
|
|
|
|
A design pattern is just a fancy term for a particular architecture that some experienced and clever people have determined is good for a particular use case. If your use case is one that has been done many times and has well defined patterns for it, then you should consider modelling your own design on one of those patterns. They are one step more specific than architectural guidelines like layering, dependency isolation, boundary interfaces etc.
Your application sounds like a fairly typical 3 tier web application and if you're starting from scratch in a .Net environment then you will probably want to use ASP.net MVC with Entity Framework or a similar ERM (e.g. NHibernate). MVC is a well specified and well tested design pattern that generally works well for that kind of application.
The important thing to remember about patterns is that they are not a prescriptive set of instructions, they're guidelines and example designs for particular scenarios. If you don't want to do quite the same thing that they did, it's natural that your design might want to be slightly different. What patterns give you is a set of initial starting points that you can use to inform your design process.
|
|
|
|
|
Just write the best code you can; either it will match an existing Pattern or it won't, no big deal.
Naming Patterns isn't really for a developer's own use; it's for developers to easily communicate ideas amongst themselves.
Think of it like ordering a pizza; the pizza shop may have a list of "named" styles, like "veggie", "meat lovers", "hawaiian", etc. but you are also free to specify toppings as you please. It may be that the set of toppings you choose happens to match one of the named styles that you aren't familiar with and the clerk may then tell you that you could just order the "greek" next time. Saying "greek" the next time will save time and may reduce confusion, but does not carry any more information than you provided the first time. Likewise, if you make a pizza at home, you wuoldn't tell yourself that you want to make a "greek" pizza, you'd would just make a pizza any way you want, and it may turn out that it matches the "greek" pizza that that pizza place offers.
As a side note, when I was first introduced to "hawaiian" pizza it had ham and pineapple. When I ordered "hawiian" pizza from a different place, the clerk asked, "well what exactly does 'hawaiian' pizza mean to you?"
Also bear in mind that not all developers understand Design Patterns exactly the same. The "Gang of Four" book is the definitive reference. Also remember that just because the Pattern has a name, it isn't necessarily a good idea.
|
|
|
|
|
Design patterns will help you structure your code.
However, if you write good code, you could probably do without design patters.
Remember a few basics like high cohesion and low coupling.
|
|
|
|
|
As you can use a delegate to set the value of a property, you can obviously use a multicast delegate to set the properties of a class.
Or you can use a binding.
What are the pros and cons of each method?
|
|
|
|
|
Delegates and (data) binding are useful in different circumstances.
Although, both can be used to change property values at runtime, multicast delegates are useful when you want to invoke multiple operations (rather than bind data) at runtime. Binding on the other hand is useful to directly set the values of properties at runtime. Binding a property to a value will not help you execute methods.
|
|
|
|
|
They are two distinct ways of communicating between entities, although you can implement data binding manually (for example where it isn't provided by the framework) using delegates and INotifyPropertyChanged fairly easily.
Data binding is typically used for a data view, generally a UI. Its purpose is to ensure that the data in the model matches what's being shown in the view, to put it in MVC/MVVM terms. No logic should happen in a data binder, although format conversions are acceptable (in WPF you can provide this as a binding argument, in WinForms you have to create a view model that's tightly bound to the view and put the conversion in there – obligatory self promotion).
Delegates are a general method to trigger code off another object's event. I'm assuming that in this context you're talking about handling change notifications on one object and updating another object as a result. This is quite similar to data binding, but the difference is that while data binding typically creates a 'vertical' binding (i.e. the view layer and model or view-model layer classes of the same concept), notifications between data objects is a 'horizontal' binding (i.e. classes in the same layer but relating to different concepts). You'd typically use delegates for this, with the handlers in a central controller class, because there is generally calculation or business logic required beyond simply assigning properties, as well as because data binding isn't typically available in such a scenario.
|
|
|
|
|
Thanks for confirming my comprehension. 
Any opinions on performance?
|
|
|
|
|
I'd expect a delegate to be faster because data binding goes through reflection, but there won't be much difference. Neither should be a bottleneck in a real system.
|
|
|
|
|
Hi Everyone!
My problem might be very easy for you but I am having difficulty trying to solve this.
I have a menu strip on my form. Currently it occupies only half the size of my form. What I am trying to do is make the menu strip items occupy the entire form, and when the form re-sizes, it will also adjust its height and/or width.
I tried setting the auto size property of the menu strip but it does not solve the problem.
Do you have any ideas guys on how to solve this? I will appreciate any kind of solution.
Thanks folks!
|
|
|
|
|
That's how MenuStrip (in fact ToolStrip, from which it derives) works. You can manually override this behavior by handling the form's resize event and increasing/decreasing the Margin property of each top-level menu item.
/ravi
|
|
|
|
|
If this is Windows Forms, an instance of a MenuStrip Control dragged on to a Form at design-time should automatically dock to the top of the Form, and fit to the entire width of the Form: that's an outcome of its default Dock Property, which is DockStyle.Top. At run-time the MenuStrip will expand, or contract, so it's always the width of the Form.DisplayRectangle.Width.
So, I am not sure I understand your question: are you perhaps wishing to have whatever Controls or MenuItems in your MenuStrip somehow distributed across the current width of the Form ?
If you seek to aid everyone that suffers in the galaxy, you will only weaken yourself … and weaken them. It is the internal struggles, when fought and won on their own, that yield the strongest rewards… If you care for others, then dispense with pity and sacrifice and recognize the value in letting them fight their own battles." Darth Traya
|
|
|
|
|
BillWoodruff wrote: Controls or MenuItems in your MenuStrip somehow distributed across the current width of the Form
I think (i.e. I assumed) that's what the OP wants to do. Goes against the standard and what users expect, IMHO.
/ravi
|
|
|
|
|
Hmm, yeah your right BiillWoodruff, it occupies the entire width but the items does not expand to maximize the remaining spaces, what I wish/want is that menu strip items are distributed across the width of the form, leaving no empty spaces.
Sorry for the confusion. Do you have solution in mind?
|
|
|
|
|
I don't know of a solution or an an example. The reason is because you're going against all normal practices and what Microsoft has baked into Windows. The philosophy is that users must have a consistent experience acrossed all applications. Controls that look the same should all work the same so as to not confuse users.
In order to do what you want, I believe you would have to owner draw the entire menu, or come up with your own menu controls without using the standard toolbox ones.
|
|
|
|
|
Thanks Dave for the reply,
Of course, I don't want user of the application to get confused, it will just expand or shrink depending on user form size or user monitor size if maximized or the reverse. The menu item is still there, it will be always visible to user, it will not change the order, just the height or width.
yeah, I might going against what microsoft baked but I find it challenging and I believe we all like challenges right?
Thanks again.
|
|
|
|
|
Did my solution not work?
/ravi
|
|
|
|
|
Thanks Ravi!
I haven't tried it out yet, I will let you know if it works.
Thanks for the idea!
Cheers!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
