|
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.
|
|
|
|
|
I got to give you 5 as this is exactly the approach I used (before I ran across IEditable). I copy the object in the selected property change and bind the editable## to the UI. Chucked the copy method in the ViewModelBase and never even think about it again!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I'm going to put my head on the block here and say that reflection works fine because while it's not the fastest solution, this tends not to matter to the user because this is not an operation they are going to be performing 1000s of times a second. That's why my solution uses reflection - it's easy to implement, easy to understand and conforms to the interfaces that WPF expects to see.
|
|
|
|
|
With silverlight4, how can i call the client program in web application? Only use Out-of-Brower, any other way?
|
|
|
|
|
What client application? Where is it running?
|
|
|
|
|
Dear Abby,
I have a bitmap that I am displaying on an Expander header.
<Image Source="{Binding TaskType, Converter={StaticResource ImageConverter}}" />
using the following ValueConverter
public object Convert(object value, Type targetType,
object parameter, CultureInfo culture)
{
System.Drawing.Image img = global::ToDoManager.Properties.Resources.Pencil;
var bitmap = new System.Windows.Media.Imaging.BitmapImage();
bitmap.BeginInit();
MemoryStream stream = new MemoryStream();
img.Save(stream, ImageFormat.Bmp);
stream.Seek(0, SeekOrigin.Begin);
bitmap.StreamSource = stream;
bitmap.EndInit();
stream.Dispose();
return bitmap;
}
which is working except that the transparent area is black. I guess I need something, encoder maybe to preserve
the transparency. It's like when I'm creating the new BitmapImage it creates it without an Alpha channel.
I've googled but everything I've found leads to this solution and people admit there's a problem but no one
has offered a solution.
Jangled in Jacksonville
C'est What?
|
|
|
|
|
|
Not really, as that's not for a WPF Bitmap.
|
|
|
|
|
Good point well put - didn't notice that!
This one[^] talks about using GDI+ in combination with WFP to get alpha channels
C# has already designed away most of the tedium of C++.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
