|
Hi,
I have a Combobox, who gets Gradient blue color when mouse-over or clicked. I managed to change the color of selecting Items background, but the mouse over background color couldn't change.
<Style x:Key="ComboStyle" TargetType="{x:Type ComboBox}">
<Setter Property="Template">
<Setter.Value>
<ControlTemplate TargetType="{x:Type ComboBox}">
<Border Name="bd" Background="{TemplateBinding Background}" BorderBrush="{TemplateBinding Background}" Padding="2">
<ContentPresenter />
</Border>
<ControlTemplate.Triggers>
<Trigger Property="IsMouseOver" Value="True">
<Setter TargetName="bd" Property="Background" Value="#F7F7F7" />
</Trigger>
</ControlTemplate.Triggers>
</ControlTemplate>
</Setter.Value>
</Setter>
</Style>
On adding the above code, MouseOver is definetely achieved i.e. Background color is changed on MouseOver. But with this, I can't see the drop down triagle icon or click the combobox that shows the drop down.
What am I lacking and ho to achieve it ? Any help is highly appreciated.
Thanks & Regards,
|
|
|
|
|
When you set the Template property, you're basically replacing the entire control. In this case, you turned a ComboBox into a ContentControl by removing (not including) all of the things that made it a ComboBox.
If all you want to change is the Background, then you should be putting this stuff directly in the Style.Triggers, not inside a Template.
For example:
<Style TargetType="ComboBox">
<Style.Triggers>
<Trigger Property="IsMouseOver" Value="true">
<Setter Property="Background" Value="Red"/>
</Trigger>
</Style.Triggers>
</Style>
|
|
|
|
|
Hi,
I am working on canvas and need to implement infinite scrolling towards the top and bottom.
I have a grid which contains the scrollviewer whose content is the custom canvas. The canvas contains some custom objects which have been drawn over the canvas and bears the drag and drop functionality.
When I drag any object towards right/bottom, scroll bars appear and gives space to put the object.
However, this functionality is not there for top/left scrolling. So, when a object is dragged towards left/top and it reaches the end, the canvas is not resized in order to accomodate the new position of object.
I know, its because canvas has a origin as 0,0 and width and height as infinite.
Currently, user has to 'Select All' all the displayed objects in the canvas and drag towards the right/bottom in order to create a new object towards left/top of it.
Searched and found this link http://www.eggheadcafe.com/software/aspnet/32319058/wpf--scroll-canvas-to-objects-beyon-top-or-left-side.aspx[] of some help, unfortunately unable to mimic the behavior in my application.
Is the use of MeasureOverride() and ArrangeOverride() method is appropriate in this situation?
The best example for infinite scrolling towards right/bottom is Excel sheet. I am looking for the same behavior for left and top.
Please let me know for any clarifications.
Thanks in advance!!!
Praveen
|
|
|
|
|
Hi,
I think the key to solve your problem could be the IScrollInfo interface. Your canvas implementation would override MeasureOverride() to calculate min and max values, ArrangeOverride() to position the items considering the scroll offsets, and implement IScrollInfo to sync the scroll offsets and constraints with the ScrollViewer.
Hope that helps.
|
|
|
|
|
Hello Experts,
I want the user to use the address only once in the browser.
For ex - if www.Xtree.com is the website name, then the user uses it in the address bar & it loads the page.Now if the user opens the page again in another tab of the browser it must throw Message that is already been used. This applies even if he browses it with other browser..
Please help me with this...
Regards,
Satish
|
|
|
|
|
What has this got to do with this forum?
|
|
|
|
|
|
Hi,
Can anyone tell me how to place a multiple window controls inside one window controls in WPF.
I have to use 4 window controls or some controls like that inside one window control, so that later i can provide the drag and drop functionality of that sub window controls for the user.
I have written a code like this, it is showing exactly what i want at design time, but at runtime it is throwing xmlparseexception, i dint get the reason for this, can u tell me what is the wrong in the below code or is it possible to place a multiple window controls inside one window control..
This is my code..
<Window x:Class="TWS_Demo_Project.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="TWS" Height="Auto" Width="Auto">
<Grid Height="Auto" Width="Auto">
<Grid.RowDefinitions>
<RowDefinition Height="Auto"/>
<RowDefinition Height="Auto"/>
</Grid.RowDefinitions>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="Auto"/>
<ColumnDefinition Width="Auto"/>
</Grid.ColumnDefinitions>
<Window Title="Order Entry" Grid.Row="0" Grid.Column="0" HorizontalAlignment="Left" VerticalAlignment="Top" Height="Auto" Width="Auto">
<Grid>
<Grid.RowDefinitions>
<RowDefinition Height="30"/>
<RowDefinition Height="30"/>
</Grid.RowDefinitions>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="150"/>
<ColumnDefinition Width="150"/>
</Grid.ColumnDefinitions>
<TextBlock Text="Name" Grid.Row="0" Grid.Column="0"/>
<TextBox Name="txtname" Grid.Row="0" Grid.Column="1"/>
<TextBlock Text="Password" Grid.Row="1" Grid.Column="0"/>
<TextBox Name="txtpassword" Grid.Row="1" Grid.Column="1"/>
</Grid>
</Window>
<Window Title="Parked Orders" Grid.Row="0" Grid.Column="1" HorizontalAlignment="Right" VerticalAlignment="Top" Height="Auto" Width="Auto">
<Grid>
<Grid.RowDefinitions>
<RowDefinition Height="30"/>
<RowDefinition Height="30"/>
</Grid.RowDefinitions>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="150"/>
<ColumnDefinition Width="150"/>
</Grid.ColumnDefinitions>
<TextBlock Text="BrokerID" Grid.Row="0" Grid.Column="0"/>
<TextBox Name="txtbrkid" Grid.Row="0" Grid.Column="1"/>
<TextBlock Text="Country" Grid.Row="1" Grid.Column="0"/>
<TextBox Name="txtcountry" Grid.Row="1" Grid.Column="1"/>
</Grid>
</Window>
<Window Title="Pending Trades" Grid.Row="1" Grid.Column="0" HorizontalAlignment="Left" VerticalAlignment="Top" Height="Auto" Width="Auto">
<Grid>
<Grid.RowDefinitions>
<RowDefinition Height="30"/>
<RowDefinition Height="30"/>
</Grid.RowDefinitions>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="150"/>
<ColumnDefinition Width="150"/>
</Grid.ColumnDefinitions>
<TextBlock Text="Pending Trade Name" Grid.Row="0" Grid.Column="0"/>
<TextBox Name="txtpndid" Grid.Row="0" Grid.Column="1"/>
<TextBlock Text="Pending Trade Details" Grid.Row="1" Grid.Column="0"/>
<TextBox Name="txtpnddetails" Grid.Row="1" Grid.Column="1"/>
</Grid>
</Window>
<Window Title="Rejected Orders" Grid.Row="1" Grid.Column="1" HorizontalAlignment="Right" VerticalAlignment="Top" Height="Auto" Width="Auto">
<Grid>
<Grid.RowDefinitions>
<RowDefinition Height="30"/>
<RowDefinition Height="30"/>
</Grid.RowDefinitions>
<Grid.ColumnDefinitions>
<ColumnDefinition Width="150"/>
<ColumnDefinition Width="150"/>
</Grid.ColumnDefinitions>
<TextBlock Text="Rejected Feed" Grid.Row="0" Grid.Column="0"/>
<TextBox Name="txtrjdfeed" Grid.Row="0" Grid.Column="1"/>
<TextBlock Text="Rejection Reason" Grid.Row="1" Grid.Column="0"/>
<TextBox Name="txtrjdreason" Grid.Row="1" Grid.Column="1"/>
</Grid>
</Window>
</Grid>
</Window>
|
|
|
|
|
You can't add a Window as the child of another Window. A window must be the root control. If I were you and you wanted to keep the headers for each section, I would change Window to GroupBox, something like this:
<GroupBox Header="Order Entry"...
<GroupBox Header="Parked Orders"...
<GroupBox Header="Pending Trades"...
<GroupBox Header="Rejected Orders"
You could also use UserControls, and then add another Label to each to display the header / title.
Hope this helps
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
|
|
|
|
|
Hi Wayne,
Thanks for replying me on my question.
I know this is possible using GroupBox, but i want the header to be just look like a window control, so when i use a drag and drop functionality for those sub windows forms it looks good..
So could you tell me how to do design like that..
or else how can i use it in User controls by converting the windows controls into user controls.
|
|
|
|
|
You can fake up your own title bar area using a rectangle and some buttons. On the rectangle, just add code to the MouseLeftButtonDown event on the rectangle and call
DragMove();
|
|
|
|
|
Well, converting to UserControl is just a matter of replacing your Window declarations with UserControl and then adding an extra row to put your title label in. Then it all just boils down to styling. I am sure if you played around a bit, you could come up with a style for the user control which would look similar to a default Window style, and bobs you uncle.
When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman
|
|
|
|
|
You can't host Window elements inside other Window elements. To achieve the effect you want, convert the inner Window items into UserControls and host those instead.
|
|
|
|
|
Suppose I have a window where user edits some details directly bound to a class (like TextBox for Person.FirstName and similar other controls). Now, such forms typicaly have "OK" and "Cancel" buttons where one saves the changes while the other leaves the data intact. If I use data binding like
<TextBox Text="{Binding Person.FirstName}" />
etc., the data is saved (to the in-memory Person object) with each change of the data in the controls. How do I cancel the changes (revert to the previous state) when the user clicks the Cancel button? I think I could use one-way data binding and somehow say "bind both ways this time" when the user clicks "Ok", but I don't know how to do that.
What is the best way how to deal with this fairly common scenario? (I would like to take advantage of data binding, if possible)
Thanks for any help, H.
|
|
|
|
|
Funnily enough, you can get this behaviour without too much trouble. Basically you need to look into IEditableObject and IEditableCollectionView to add this functionality. I blogged about it here[^].
|
|
|
|
|
Not a good idea to re-invent the wheel here. You should stick with IEditableObject since that is the "standard" way of doing it. Doing it the "standard" way has the benefit of clean integration with controls.
|
|
|
|
|
Lots of problems with your solution:
1) reflection is slow
2) only supports public, simple properties... what about private and/or complex properties? what about nested properties?
3) reference objects will get set in both copies, no?
4) will not work with controls that require IEditableObject
|
|
|
|
|
Collin Jasnoch wrote: Soo how do you expect the IEditableObject to do this work??? (if you read Pete's
blog he even says that his EditableObject uses reflection....). Also reflection
is not that slow. I mean if this has to occur over and over (like 100's of time
in seconds.. why would this be though???) and the object is very large (consider
refactoring) you may want a different option (again.. I do not see how the
IEditableObject solves this.. it is merely an interface, NOT an implimentation
of it).
Are you familiar with how IEditableObject works? You just implement 3 standard methods any way you want. If I was doing it? Well, I'd have my base object implement ICloneable and use that to clone the object properly. That has the benefit of being another standard interface that other people might want to use and is more performant then reflection. You *COULD* implement your ICloneable to copy the object with reflection, but thats just plain silly.
I highly suggest you run some performance benchmarks on reflection and see just how slow it is.
Collin Jasnoch wrote: So were you planning on binding some UI elements to private properties??? Or
'Complex' properties as you put it? If so, the logic is already there... Because
you already implimented it. Also, if you want it to support private fields you
can certainly impliment that (I did not because I had no need for it)
OK, adding support for private properties was just a minor nitpick and that is trivial... but yeah, I'm binding to a complex property right now as I type this. How is your code going to handle:
Dictionary<string, Dictionary<string, CMTInfo[]>>
?
Thats a valid "complex" type that I'm binding to a TreeView.
Collin Jasnoch wrote: Do you really think the OP requires this anywhere???
Yeah, cuz, NOBODY uses the data grid  . Data grid used IEditableObject as one example of a popular control that uses it.
Collin Jasnoch wrote: On a last point, even if you provide a nice implimentation of IEditableObject
(that somehow does NOT use reflection), you are now forcing a base class on an
object for simple functionality (see post above.. what like 10 lines of
code).
Whats your point? Anything you bind to in the UI needs to implement INotifyPropertyChanged / INotifyCollectionChanged anyways. Whats another small interface?
Anyways, even if you want to use the code you posted above, thats fine, but I'd still wrap it in an IEditableObject interface so it can be used with controls.
My initial objection was not that you were using reflection (although it IS slow and you aren't caching ANY of the really slow reflection methods), it was that you weren't using IEditableObject.
|
|
|
|
|
If its inside the object itself, I would just do a prop by prop copy. Expression trees are 1000x faster then reflection for get/set, but the startup cost is more, so those are more useful when you are getting the same prop over and over and can cache the lambda.
|
|
|
|
|
Some times I feel programmers get a bit carried away with implementing code. Building a dragster to take a midnight stroll around town for instance is a bit overkill. The poster simply asked for a process that would work for his issue. It seems both of you have valid ways on how to approach this but one thing remains which method is simpler to comprehend. Giving an explanation to some one that is more complex than he requires, while sound in theory, may not be the right solution for his particular issue. I'm still a big fan of if it works to fix the problem use it. You don't regrow an entire leg to fix a small cut you slap a band-aid on it.
I know you can argue that implementing the wrong programming techniques can potentially lead to problems in the future, but you can run into issues even using the correct ones. Now I apologize for derailing this gentleman's thread but after reading this I became even more confused as to how to accomplish the original question. I can just imagine that he may be just as confused.
Sometimes it helps to remember that people post here because they don't have the answers, and we need to remember not everyone can comprehend at the same level.
|
|
|
|
|
As I indicated to the other poster, it is (potentially) important to implement STANDARD interfaces rather then employing band-aid fixes. Just like WPF relies on you implementing INotifyPropertyChanged, some aspects of it rely on you implementing IEditableObject. The discussion got derailed on how the internals should work rather then the outside of the black box.
|
|
|
|
|
Thank you all guys, only now did I get the time to read all posts. To summarize what I learned:
1) .NET ships with IEditableObject interface which I am advised to implement in such situations
2) the implementation may use reflection, expression trees (not sure I quite understand this), or can be manually typed out for a particular class
3) the implementation (in any case) does nothing other that store a copy of the data for possible rollback later
4) .NET framework itself provides no extra advantage of using IEditableObject (except data grid and maybe few other specific controls) - a typical window with textboxes and checkboxes for data is unaware of IEditableObject and I must manually call BeginEdit, CancelEdit etc.
Therefore - if I just make the copy but not as an implementation of IEditableObject, it'll work the same, but it is not advisable because it is not standard practice.
Let me please know if I understand this correctly.
H.
|
|
|
|
|
Basically, that's spot on. Although it also ships with IEditableCollectionView which you may want to take advantage off if you are adding to collections.
|
|
|
|
|
That is kind of disappointing. Because really - the easy solution would be this: bind data model->controls only once. Do not bind back until said so (ie - user clicks OK). Maybe this would stand in the way of other things like validation, I don't know, but still I would expect that .net framework comes a bit more prepared for this very common scenario other than provide an interface any kid could write and let programmers worry about the rest.
Anyway, thanks for helping me understand this.
|
|
|
|
|
Did you download and try the sample in my blog entry? Basically I created a couple of reusable classes in there that you can just use in your project without needing to reinvent any wheels.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
