|
|
Good people,
How do I enable a TextBox to allow empty returns. For example, when I press enter, it will allow a new line or blank lines if I press it multiple times.
Sort of like what I did to get to this new line, I just pressed enter a few times.
Thanks for any information you can provide.
Blitz
|
|
|
|
|
Set the following properties in your textbox TextWrapping="Wrap" AcceptsReturn="True"
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
Thanks, I really appreciate it.
Blitz
|
|
|
|
|
Hi,
WPF is still a nerw technology for me and now I am in trouble with static ressources.
Actually:
I've made a TextBlock which should be changing its static ressource on click event!
So I have made two styles.
1. Style x:Key="CalendarDayStyle" TargetType="TextBlock"
2. Style x:Key="SelectedCalendarDayStyle" TargetType="TextBlock"
The TextBlock normally is set to
Style="{StaticResource CalendarDayStyle}"
Trying things like
((TextBlock)sender).Style = Style="{StaticResource SelectedCalendarDayStyle}";
is not working.
How can I solve this. Maybe I am wrong and static resource can not be changed from code behind.
cu s00n
eXi
|
|
|
|
|
Keep in mind that the "Style" property is still a property that takes a Style instance. The StaticResource markup extension is just a helper class that looks up a named resource (of type STYLE) and assigns it to that property.
Accordingly, in code, you need to look up the style resource yourself and assign it - StaticResource is nothing you are using at this time. What you are looking for is the FindResource method.
However, changing a style in code behind to switch the look when a textbox is selected is not the WPF way of doing things. Usually, you just write one style and use triggers to exchange the look as soon as the textbox is selected. Do a short Google search - there are tons of samples around.
hth, Philipp
NetDrives - Open Source Network Share Management Awesomeness
|
|
|
|
|
Thank you for pointing us in the right direction. 
|
|
|
|
|
You can change a resource from code behind, but it's important to understand that XAML code in {} sections is actually syntactic sugar for a fairly complex binding mechanism. What you would need to do would be to use FindResource to find the appropriate resource and apply it.
A better way (and the correct WPF way) would be to apply a data trigger to the Click event where you applied the style in the XAML. This has the advantage that the WPF binding mechanism would only apply the style while the item was clicked - it resets it once the click has finished.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
Suppose I have a resource file like this
<UserControl.Resources>
<Style x:Key="LightGrayBackground" TargetType="{x:Type igEditors:XamTextEditor}">
<Setter Property="Background" Value="LightGray"></Setter>
</Style>
</UserControl.Resources>
Now I will access this
TryFindResource("LightGrayBackground") as Style
Niladri Biswas
|
|
|
|
|
try this
TextBlockID.Style = DirectCast((App.Current.Resources("CalendarDayStyle")), Style)
your app like this
<Application.Resources>
<ResourceDictionary>
<ResourceDictionary.MergedDictionaries>
<ResourceDictionary Source="Assets/Styles.xaml">
<ResourceDictionary.MergedDictionaries>
<ResourceDictionary>
<Application.Resources>
|
|
|
|
|
Hi all,
I am a german developer in C#, c/c++ and others. Just a few weeks I have been start to learn WPF with C#!
No I am trying to write a wpf styled DateTimePicking Form and it is nearly finished.
But I have some Problems with the Styles.
1. I have made the list view with binding to a property which contains 7
fields for each week. Now I have a monthly display of the days, but
I can only click the whole row. How can I select a single subitem
from this wpf list view?
2. I also need a possibility to read this selected value (day).
3. The ListView Header have a separator, which is changing the
width. But how can I prevent resizing the columns?
4. The ListView Headers have a mouse over effect. How can I
disable the mouse over effevt for the Headers only?
regards,
eXi
|
|
|
|
|
You could probably dig into the ListView style and template to get what you want,
but I personally would use the DataGrid control from the WPF toolkit (assuming you're
using the Grid view on your ListView).
Using the DataGrid, getting your desired look and feel (single cell select, no resizing
columns, no header mouseover effect) would be as simple as something like this:
<wpftk:DataGrid x:Name="dataGrid1" AutoGenerateColumns="True" SelectionUnit="Cell" SelectionMode="Single"
CanUserResizeColumns="False" CanUserSortColumns="False"
ItemsSource="..." GridLinesVisibility="All" VerticalGridLinesBrush="Black" HeadersVisibility="Column"
AlternatingRowBackground="LightSteelBlue" Height="300" >
<wpftk:DataGrid.ColumnHeaderStyle>
<Style TargetType="{x:Type wpftk:DataGridColumnHeader}" BasedOn="{StaticResource {x:Type wpftk:DataGridColumnHeader}}">
<Setter Property="Background" Value="SteelBlue" />
<Setter Property="Foreground" Value="White" />
<Setter Property="HorizontalContentAlignment" Value="Center" />
</Style>
</wpftk:DataGrid.ColumnHeaderStyle>
</wpftk:DataGrid>
*edit* Also, see Jaime Rodriguez's three part article on the DataGrid:
Dabbling Around the New WPF DataGrid[^]
It's a little "old" but covers the basics well
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
modified on Saturday, May 9, 2009 5:17 PM
|
|
|
|
|
Good Morning,
thanks a lot for you reply.
Actually I solved it with a TextBlock-Collection, sure this is not a clean way to develope, but it works.
The DataGrid will be interesting and I will get into it in the next days.
cu s00n
eXi
|
|
|
|
|
Hi all,
Is there a way to run wpfbrowser application in linux?
Thanks in advance....
Krishnraj
|
|
|
|
|
|
I have a button on a control, which itself is on a window. The window doesn't know about the button, but it needs to handle the event. The way I've been doing it up to now is to add x:FieldModifier="public" to the button, but that somehow feels wrong (even though it works).
Is this the most proper way to handle event in this situation, or is there a more WPF-appropriate way to do it?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
The standard .NET way to do this is for the user-control to have an event that exposes the internal event. If the button is called say "Save", then the user-control will have a Save event, and the Save event will be internally fired from the click handler for the button. The window now handles this exposed event on the user-control.
Making the user-control's button public is not a very good approach at all (like you said). That's a typical VB6-ish way of doing things.
|
|
|
|
|
What's the benefit of routed events then? If it's not automatic in some way, what's the point?
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
John Simmons / outlaw programmer wrote: What's the benefit of routed events then? If it's not automatic in some way, what's the point?
In this particular case routing this event (either via bubbling or tunneling) won't be very natural. That would apply in a different scenario - say you have a user-control with some child-textbox controls. Now say you want a double-click event on the user-control that will fire even when the textbox control's double click is fired (and not just when a blank area within the user-control is double clicked). In this scenario, the textbox's event handler should bubble it up to the parent. It sounds a little weird but that's the way things seem to be done in WPF.
|
|
|
|
|
I agree with Nish...I would keep knowledge of the button internally encapsulated
in the control class and only publicly expose any required functionality...regular
OOP stuff, which allows you to change the controls innards without changing the public
interface.
As far as routed events - routing is along the visual/logical trees - not really
applicable to what you're asking I don't think.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Well it is actually a bad design decision (good thing this isn't production code). I didn't want a full-on toolbar because of the decorations that are added to them by default (and I really didn't have time to figure out how to hide them). So, I created a user control that serves as the toolbar. Bad idea, because I now have the implementation crap to deal with in terms of being able to see the button from (a) the window that contains the control and b) tabs in the window that contains my faux-toolbar user control.
I was sitting around today getting pissed off at WPF, and re-implemented the faux-toolbar as a stackpanel/grid combination, this time, directly on the window instead of as a user control. This means I still have to make the buttons public, or manually implement an event forwarding mechanism, and as indicated, I know the technically most correct action to take, but the lazy redneck in me is satisfied with making the buttons public. I was just wondering if I was missing a concept of routed events, and apparently, I'm not. It's the same old sh*t with a shiny new name and an obscure reason for existing.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Depends on what you are trying to do. If a button click should cause some change on the model rather than the UI, you should look into commands and leave the Window completely out of the picture. In that case, you set the Command property of the button rather than handling the click event.
If you want to bubble the click event on a higher level, you can just register an event listener on a higher level through XAML:
<SomeContainerControl Button.Click="MyEventHandler">
<SomeChildControl>
<!-- clicks bubble up the visual tree -->
<Button x:Name="myPrivateButton" />
</SomeChildControl>
</SomeContainerControl>
hth, Philipp
NetDrives - Open Source Network Share Management
|
|
|
|
|
If he has multiple buttons, he'd have to switch-case on the Text or Name properties. In this case, I believe handling a custom event on the user-control is a better approach than handling the bubbled event.
|
|
|
|
|
...which is where I would opt for different commands (or alternatively: command parameters). And he stated that the window does not know about the button (which indicates separation of concerns on the UI level). However, it's hard to tell without knowing the use case 
Cheers,
Philipp
NetDrives - Open Source Network Share Management
|
|
|
|
|
John - to be honest, you need to look at using MVVM (definitely a version with the Mediator pattern as part of it). This architecture is designed to cope exactly with scenarios like this.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
