ResourceDictionary swapped at run-time only applies to MainWindow - WPF Discussion Boards

Re: Executing a WPF .exe program from an email link

5-Aug-16 9:40

I found the answer:

script language=JavaScript

function launchExecutable(executableFullPath)

{

 var shellActiveXObject = new ActiveXObject("WScript.Shell");

 shellActiveXObject.Run(executableFullPath, 1, false);

 shellActiveXObject = null;

}

script

Dave Kreskowiak5-Aug-16 9:45

Dave Kreskowiak

5-Aug-16 9:45

That might work in your environment but it won't work in mine. Yes, we use Outlook/Exchange. Policies prevent us from doing what you came up with, for very obvious security reasons.

A guide to posting questions on CodeProject

Click this: Asking questions is a skill.
Seriously, do it.

Dave Kreskowiak

Re: Executing a WPF .exe program from an email link

Richard MacCutchan5-Aug-16 20:42

Richard MacCutchan

5-Aug-16 20:42

That is only ever going to work on your system so there is little point in trying to run it from an email message.

Re: Executing a WPF .exe program from an email link

Gerry Schmitz6-Aug-16 7:07

Gerry Schmitz

6-Aug-16 7:07

Create a service (Windows service; FileWatcher event handler; SQL Server agent; whatever) that monitors for the arrival and related events of the email(s) in question; and then kicks off the WPF app.

Or have the WPF app "hide" (and monitor) until the email arrives and triggers a "show".

Event triggers and handlers.

Re: Executing a WPF .exe program from an email link

Stephen Holdorf7-Aug-16 11:26

Re: Executing a WPF .exe program from an email link

7-Aug-16 11:26

I understand having a windows service monitor an event but what event in the email would kick off the Windows service starting the app and how would the parameter be accessed by the app on startup?

Gerry Schmitz7-Aug-16 12:16

Gerry Schmitz

7-Aug-16 12:16

You start by examining how your mail is received, where it is stored, and what events are associated with it. At the very least, the contents of a given folder (or database) will be updated which can be monitored by a File Watcher (or other "monitor") class instance.

Get your "link" to save something if you can't figure the rest out.

ResourceDictionary swapped at run-time only applies to MainWindow

Imagiv5-Aug-16 6:51

Imagiv

5-Aug-16 6:51

I have a class that derives from Window and I use it for ALL windows in my application. I have a resource dictionary for themes contained in App.xaml, which looks like this:

<Application [...]>
    <Application.Resources>
        <ResourceDictionary>
            <ResourceDictionary.MergedDictionaries>
                <ResourceDictionary x:Name="ThemeDictionary">
                    <ResourceDictionary.MergedDictionaries>
                        <ResourceDictionary Source="/Themes/MyTheme.xaml"/>
                    </ResourceDictionary.MergedDictionaries>
                </ResourceDictionary>
            </ResourceDictionary.MergedDictionaries>
        </ResourceDictionary>
    </Application.Resources>
    [...]
</Application>

The style for my derived window type is located in an external assembly and declared using Generic/Themes.xaml pattern.

For switching the theme, I remove the existing theme dictionary and replace it with the new one. Oddly, the changes in styles only reflect in MainWindow and not in any additionally created windows.

My derived window type is styled like this:

<ControlTemplate x:Key="WindowTemplate" TargetType="{x:Type Controls:CustomWindow}">
    [...]
</ControlTemplate>
<Style x:Key="{x:Type Controls:CustomWindow}" TargetType="{x:Type Controls:CustomWindow}" BasedOn="{StaticResource CustomWindowStyle}">
    [...]
</Style>

Note, the theme specified at design-time always works in ALL windows; however, any themes specified at run-time only apply to MainWindow and never additional windows.

Any idea why this is?

Re: ResourceDictionary swapped at run-time only applies to MainWindow

Richard Deeming5-Aug-16 7:02

Richard Deeming

5-Aug-16 7:02

Have you tried calling BeginInit and EndInit on the main resource dictionary?

ResourceDictionary toRemove = ...;
ResourceDictionary toAdd = ...;

Resources.BeginInit();
try
{
    if (toRemove != null)
    {
        Resources.MergedDictionaries.Remove(toRemove);
    }
    if (toAdd != null)
    {
        Resources.MergedDictionaries.Add(toAdd);
    }
}
finally 
{
    Resources.EndInit();
}

"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer

Re: ResourceDictionary swapped at run-time only applies to MainWindow

Imagiv5-Aug-16 7:18

Imagiv

5-Aug-16 7:18

I applied your suggestion and the method that sets the dictionary is now as follows:

public Result Set(string Path)
{
    Result Result = null;
    ResourceDictionary NewDictionary = this.Get(Path);
    this.Dictionary.BeginInit();
    try
    {
        if (this.Dictionary != null && NewDictionary != null)
        {
            this.Dictionary.Clear();
            this.Dictionary.MergedDictionaries.Add(NewDictionary);
            Result = new Success();
        }
    }
    catch (Exception e)
    {
        Result = new Error(e.Message);
    }
    finally
    {
        this.Dictionary.EndInit();
    }
    return Result;
}

Where NewDictionary is a resource dictionary read from a file and this.Dictionary is the resource dictionary containing the merged dictionaries.

Unfortunately, this doesn't change anything.

KeepTextBoxDisplaySynchronizedWithTextProperty

Kevin Marois28-Jul-16 7:18

Re: KeepTextBoxDisplaySynchronizedWithTextProperty

28-Jul-16 7:18

I just found this in our app's CTOR:

System.Windows.FrameworkCompatibilityPreferences.KeepTextBoxDisplaySynchronizedWithTextProperty = false;

MSDN Says [^]

Gets or sets a value that indicates whether a data-bound TextBox should display a string that is identical to the value of the source its Text property

As is typical with MSDN, this explanation says nothing of value.

Why wouldn't a textbox display what's in its Text property by default?

Anyone ever used this? Can you shed some light on what this really means?

If it's not broken, fix it until it is

Matt T Heffron28-Jul-16 7:33

Matt T Heffron

28-Jul-16 7:33

I've never used it but it looks like it is referring not to the Text property of the TextBox, but to the source that is data bound to the Text property.
From looking at the code it appears it has to do with an edge case where the TextBox is pushing a change back to the binding source but may not notice if the binding source has modified that string.

// when Text is data-bound, _newTextValue is converted from a
// deferred reference to a string.  The binding writes the string
// back to the source, then computes a new value for Text (which
// may be different, either because the source normalizes the value
// or because of conversion and formatting).  Usually this raises
// a change notification for Text, which brings the Text property and
// the text container into [....].  But this doesn't happen in one
// case:  when the normalized value is the same as the original
// value for Text.  The property engine thinks that Text hasn't
// changed, and doesn't raise the notification.  It's true that
// Text hasn't changed, but we still need to update the text container,
// which now displays the wrong value.
// We detect that case by checking whether _newTextValue (the
// text container value) agrees with Text.

"Fairy tales do not tell children the dragons exist. Children already know that dragons exist. Fairy tales tell children the dragons can be killed."
- G.K. Chesterton

Re: KeepTextBoxDisplaySynchronizedWithTextProperty

Kevin Marois28-Jul-16 7:39

Creating a line break to keep visible tabitems from wrapping when other tabitems become visible.

28-Jul-16 7:39

Just found this[^]

Seems like a good explanation, although this property seems to be because of a bug.

If it's not broken, fix it until it is

Stephen Holdorf28-Jul-16 3:16

Re: Creating a line break to keep visible tabitems from wrapping when other tabitems become visible.

28-Jul-16 3:16

I have tried a lot of things without luck. What I'm trying to do is create a XAML TabControl that keeps all of the first five visible TabItems on the first row when the last two hidden TabItems become visible. What I want is for the two last TabItems to wrap when they become visible but keep the first five on the first row. I have tried to use a TextBlock with a LineBreak but when the last two TabItems become visible the fifth TabItem wraps with the new visible last two TabItems. Any help would be great.

Stephen Holdorf28-Jul-16 14:41

28-Jul-16 14:41

The answer to my problem had to do with setting the widths of the collapsed tabs once they were changed to visible. What I did was give the newly visible tabs the correct width and they pushed the other tabs to the first row.

DP not Working

Kevin Marois27-Jul-16 8:01

27-Jul-16 8:01

This is a very simple example, and I can't get it to work

My UserControl

<Grid>
    <Border>
        <TextBlock Text="{Binding DayNameCaption}"
                    Background="Green"
                    Foreground="White"
                    Height="25"
                    Width="75"/>
    </Border>
</Grid>

Code Behind

public partial class MonthViewDayColumnHeader : UserControl
{
    #region DP DayName
    public static readonly DependencyProperty DayNameCaptionProperty =
        DependencyProperty.Register("DayNameCaption",
            typeof(string),
            typeof(MonthViewDayColumnHeader),
            new PropertyMetadata("Today", 
            new PropertyChangedCallback(OnDayNameCaptionChanged), 
            new CoerceValueCallback(CoerceDayNameCaption)));

    public string DayNameCaption
    {
        get { return (string)GetValue(DayNameCaptionProperty); }
        set { SetValue(DayNameCaptionProperty, value); }
    }

    private static void OnDayNameCaptionChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        MonthViewDayColumnHeader control = (MonthViewDayColumnHeader)d;
        var dayNameCaption = control.DayNameCaption;  // dayNameCaption is null
    }

    private static object CoerceDayNameCaption(DependencyObject d, object value)
    {
        MonthViewDayColumnHeader control = (MonthViewDayColumnHeader)d;
        var dayNameCaption = control.DayNameCaption;   // dayNameCaption is 'Today', the default value
        return null;
    }
    #endregion

    #region CTOR
    public MonthViewDayColumnHeader()
    {
        InitializeComponent();

        this.DataContext = this;
    }
    #endregion
}

Usage:

<Grid>
    <schedule:MonthViewDayColumnHeader DayNameCaption="Monday" 
                                        Height="50"
                                        Width="120"/>
</Grid>

The text "Monday" doesn't show up.

WTF IS WRONG HERE!!!!

If it's not broken, fix it until it is

Gerry Schmitz27-Jul-16 15:44

Gerry Schmitz

27-Jul-16 15:44

Over-engineering.

Kevin Marois27-Jul-16 16:38

27-Jul-16 16:38

Thanks for your thoughtful response. That fixed it.

If it's not broken, fix it until it is

PureNsanity28-Jul-16 12:50

PureNsanity

28-Jul-16 12:50

The reason why it's not working is the MonthViewDayColumnHeader class doesn't support INotifyPropertyChanged. It's being initialized, then updated with Monday after. If you take the existing and default it to 'Sunday' you should be able to see the default value.

On that note, I know it's an example but you should probably start off with MVVM in your learning process. Have the underlying layers implement the INotifyPropertyChanged and set the context to an appropriate view model.

Kevin Marois28-Jul-16 13:29

28-Jul-16 13:29

Actually, it wasn't working because I'm a dumba$$...

private static object CoerceDayNameCaption(DependencyObject d, object value)
    {
        MonthViewDayColumnHeader control = (MonthViewDayColumnHeader)d;
        var dayNameCaption = control.DayNameCaption;value
        return null;   //<=== ALWAYS RETURNS NULL
    }

changed it to

private static object CoerceDayNameCaption(DependencyObject d, object value)
    {
        MonthViewDayColumnHeader control = (MonthViewDayColumnHeader)d;
        var dayNameCaption = control.DayNameCaption;value
        return dayNameCaption ;   //<=== NOW IT WORKS
    }

If it's not broken, fix it until it is

PureNsanity28-Jul-16 13:51

PureNsanity

28-Jul-16 13:51

Yes and no. You shouldn't be using a callback in this case. The callback is circumventing the whole point of the binding. Taking my advice would fix it the appropriate way.

Kevin Marois28-Jul-16 14:14

28-Jul-16 14:14

Well, actually, I put in the callback for testing and ended up breaking my code Poke tongue | ;-P

If it's not broken, fix it until it is

Richard Deeming29-Jul-16 2:11

Richard Deeming

29-Jul-16 2:11

I assume the rogue ;value is just a typo in your message?

var dayNameCaption = control.DayNameCaption;value // <-- This won't compile.

"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer

Richard Deeming29-Jul-16 2:12

Richard Deeming

29-Jul-16 2:12

You don't need to implement INotifyPropertyChanged when you're using dependency properties.
DependencyProperties or INotifyPropertyChanged ?[^]

"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer