Cinch Discussions Rss Feed

New Post: Build errors in CinchV2

at1087 — Tue, 16 Apr 2013 14:54:44 GMT

Where is that word document for this error?
Thanks

New Post: Getting RaiseFocusEvent to work

daspn — Wed, 20 Feb 2013 20:22:18 GMT

No problem!

Thanks for replying.

New Post: Getting RaiseFocusEvent to work

sachabarber — Wed, 20 Feb 2013 16:04:55 GMT

Sorry I have been on holiday. To be honest if that is what your need is, I see nothing wrong with what you have done.

That's really the only advise I can give you.

New Post: Getting RaiseFocusEvent to work

daspn — Wed, 13 Feb 2013 16:12:06 GMT

Hi Sacha,

I know this thread is quite old but I have recently started using your fantastic Cinch framework and although your proposed solution will probably work fine (IFocusable thing), I wrote an extension method for the ViewModelBase using a Timer to "wait" for the FocusRequested to be available:

public static class ViewModelBaseExtensions
{
    public static void RaiseFocusEvent(this ViewModelBase viewModelBase, IViewAwareStatus viewAwareStatusService, string focusProperty)
    {
        var timer = new Timer();

        timer.Elapsed += (source, e) =>
        {
            viewAwareStatusService.ViewsDispatcher.InvokeInBackgroundIfRequired(() =>
                {
                    timer.Stop();
                    timer.Dispose();
                    viewModelBase.RaiseFocusEvent(focusProperty);
                }
            );
        };

        timer.Start();
    }
}

This works fine and I use it in a regular ViewModelBase-derived class:

public void InitialiseViewAwareService(IViewAwareStatus viewAwareStatusService)
{
    this.ViewAwareStatusService = viewAwareStatusService;
    this.ViewAwareStatusService.ViewLoaded += ViewLoaded;
}


private void ViewLoaded()
{
    this.RaiseFocusEvent(this.ViewAwareStatusService, "PropertyName");
}

Delayed execution is often seen as bad design and I would appreciate your opinion in this case.

Thank you,
Daniel

New Post: .NET 4.5 and caller information

sachabarber — Sun, 30 Dec 2012 12:01:20 GMT

Sorry about taking so long to get back to you on this, I tried using my IPhone but it crapped out on me.

I totally agree you could do this, and there is nothing stopping anyone doing this, and since the Cinch VM base classes are partial, you could indeed create a new method called "NotifyUsingCaller" or something. Nothing stopping you doing just that.

For me I just want to keep Cinch as clean as possible.

New Post: .NET 4.5 and caller information

Disore — Thu, 20 Dec 2012 15:31:28 GMT

I agree with your regards to .NET 4.5, however it is possible to use Caller Info without moving to .NET 4.5. Just create a file with the following content in your .NET 4 project (only tested in WPF):

----------------------------------------------------------------------------------------

using System;

using System.Runtime;

namespace System.Runtime.CompilerServices

{

/// <summary>

/// Allows you to obtain the method or property name of the caller to the method.

/// </summary>

[AttributeUsage(AttributeTargets.Parameter, Inherited = false)]

[__DynamicallyInvokable]

public sealed class CallerMemberNameAttribute : Attribute

{

[__DynamicallyInvokable]

[TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")]

public CallerMemberNameAttribute()

{

}

/// <summary>

/// Allows you to obtain the full path of the source file that contains the caller. This is the

/// file path at the time of compile.

/// </summary>

[AttributeUsage(AttributeTargets.Parameter, Inherited = false)]

[__DynamicallyInvokable]

public sealed class CallerFilePathAttribute : Attribute

{

[__DynamicallyInvokable]

[TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")]

public CallerFilePathAttribute()

{

}

/// <summary>

/// Allows you to obtain the line number in the source file at which the method is called.

/// </summary>

[AttributeUsage(AttributeTargets.Parameter, Inherited = false)]

[__DynamicallyInvokable]

public sealed class CallerLineNumberAttribute : Attribute

{

[__DynamicallyInvokable]

[TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")]

public CallerLineNumberAttribute()

{

}

internal sealed class __DynamicallyInvokableAttribute : Attribute

{

[TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")]

public __DynamicallyInvokableAttribute()

{

}

----------------------------------------------------------------------------------------

As regards to your second argument:, I also like use a syntax where multiple properties are stated, but that doesn't take anything away from the Caller Info version of sending property changed, it only extends the toolkit a developer can use when sending those events.

using System;

using System.Runtime;

namespace System.Runtime.CompilerServices

{

/// <summary>

/// Allows you to obtain the method or property name of the caller to the method.

/// </summary>

[AttributeUsage(AttributeTargets.Parameter, Inherited = false)]

[__DynamicallyInvokable]

public sealed class CallerMemberNameAttribute : Attribute

{

[__DynamicallyInvokable]

[TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")]

public CallerMemberNameAttribute()

{

}

/// <summary>

/// Allows you to obtain the full path of the source file that contains the caller. This is the

/// file path at the time of compile.

/// </summary>

[AttributeUsage(AttributeTargets.Parameter, Inherited = false)]

[__DynamicallyInvokable]

public sealed class CallerFilePathAttribute : Attribute

{

[__DynamicallyInvokable]

[TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")]

public CallerFilePathAttribute()

{

}

/// <summary>

/// Allows you to obtain the line number in the source file at which the method is called.

/// </summary>

[AttributeUsage(AttributeTargets.Parameter, Inherited = false)]

[__DynamicallyInvokable]

public sealed class CallerLineNumberAttribute : Attribute

{

[__DynamicallyInvokable]

[TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")]

public CallerLineNumberAttribute()

{

}

internal sealed class __DynamicallyInvokableAttribute : Attribute

{

[TargetedPatchingOptOut("Performance critical to inline this type of method across NGen image boundaries")]

public __DynamicallyInvokableAttribute()

{

}

New Post: WeakEvent Type parameter

sachabarber — Thu, 20 Dec 2012 13:32:24 GMT

Sorry its taken me so long to do this, but I finally fixed that line of code in there

New Post: .NET 4.5 and caller information

sachabarber — Thu, 20 Dec 2012 12:48:54 GMT

I don't really want to use that, as it would be putting something quite 4.5 specific in there.

Also I do like the ability to notify different properties, and maybe even more than 1 at a time, which is why I never went for a DepedencyProperty type thing for Cinch. Read more here : http://awkwardcoder.blogspot.co.uk/2012/07/callermembername-not-that-great-for.html

New Post: Cinch v2 and ServiceLocator.Current

sachabarber — Thu, 20 Dec 2012 12:43:25 GMT

Cool, glad you are all fixed

New Post: Cinch V2 and .net 4.5

sachabarber — Thu, 20 Dec 2012 12:42:18 GMT

I wish I had an answer for you all on this one, truth is I just don't know what could cause this issue

New Post: .NET 4.5 and caller information

Disore — Wed, 12 Dec 2012 21:51:19 GMT

Hi.

Are there any plans to use CallerMemberNameAttribute in the NotifyPropertyChanged method of the view model base classes?

New Post: Cinch v2 and ServiceLocator.Current

Disore — Mon, 10 Dec 2012 17:55:18 GMT

It was my own fault. I configured the bootstrapper according to Demo 1 in http://www.codeproject.com/Articles/145175/Showcasing-Cinch-MVVM-framework-Prism-4-interopera, I should have used the bootstrapper in Demo 2.

New Post: Cinch v2 and ServiceLocator.Current

Disore — Sun, 09 Dec 2012 22:54:30 GMT

I am having problems using ServiceLocator.Current when my application uses Cinch version 2. Some of my classes are marked with:

[PartCreationPolicy(CreationPolicy.Shared)]

but it doesn't seem to be respected since two instances are created.

The first instance is created when any class has declared the type as [Import], and the second instance is created when calling ServiceLocator.Current.GetInstance<...>().

Does anybody know what is happening?

New Post: Cinch V2 and .net 4.5

Endimion — Fri, 26 Oct 2012 05:46:24 GMT

Everything you said applies to me, and you are correct, the error dosent halt your aplication, it still compiles, and seems to work. But it will feel much better if the errorr was not there, and it would also increase my confidence on the code I am writting.

Hopefully some one here has a full understanding of this problem and would shed some light on the issue :)

New Post: Cinch V2 and .net 4.5

JeffreyHare — Thu, 25 Oct 2012 16:17:49 GMT

I will add my experiences here. I have a CinchV2 project that I built with VS2010. When I use VS2012 (staying with .net 4.0 for the project) I also have these same issues with any of the behaviors and triggers, event to command etc..

What I find is that if I open the XAML, I see the errors you refer to in the error window and the intellisense errors in the XAML code. But close the xaml files and rebuild all and the program seems to run and behave as intended.

So, I'll show my ignorance here but is it possible that there is some disconnect between the assemblies Visual studio uses to compile the xaml for the designer and that which the application uses at runtime?

Also, if I build under VS2010 and then open the project under VS2012, the intellisense/XAML seems happy until I clean the solution. If I don't open the XAML files or Designer, I seem to be able to build, edit and run happily without any errors in the error window.

Does any of this seem like what you're seeing?

I'd also *really* love to understand why this is and what I can do about it.

New Post: Cinch V2 and .net 4.5

Endimion — Thu, 25 Oct 2012 11:00:28 GMT

Hi, I am using Cinch V2 on a VS2012 project targeting the .net 4.5 framework. Everything works fine but I am getting this error that I dont had when using VS2010 and the .net 4.0

The type 'TextBoxFocusBehavior' from assembly 'Cinch.WPF' is built with an older version of the Blend SDK, and is not supported in a Windows Presentation Framework 4 project

This is the XAML:

I have the latest version of Cinch V2, I took the code base and rebuild it, I also tried to make sure I was using the latest interactivity libraries.

I was wandering if anyone had encuenter this issue and how they solved it.

New Post: WeakEvent Type parameter

sachabarber — Wed, 17 Oct 2012 18:32:17 GMT

Ah cool Ill try and get that fixed in Cinch. Probably as you say no has tried EventArgs. Ill fix it

New Post: WeakEvent Type parameter

rschwenn — Wed, 17 Oct 2012 17:51:14 GMT

Yes, I found it in Daniels article: http://www.codeproject.com/script/Articles/ViewDownloads.aspx?aid=29922.

Yes, it fixes the issue that only classes derived of EventArgs could be used. With the changed line of code the EventArgs class itself can be used, too.

Yes, classes derived of EventArgs still work well for me.

Maybe nobody has tried to use EventArgs directly ;-)

New Post: WeakEvent Type parameter

sachabarber — Wed, 17 Oct 2012 12:02:53 GMT

I am not sure what you are saying here, are you saying you got code from Daniels article that fixed your issue, as it allowed you to use EventArgs?

I never changed that code, so I guess Daniel must have changed him mind at some stage. Does your new line of code also work with Subclasses of EventArgs?

I have never had an issue with it to be honest. Perhaps if you could just clarify I could update the codebase.

New Post: WeakEvent Type parameter

rschwenn — Fri, 12 Oct 2012 17:32:16 GMT

I had a look at Daniels FastSmartWeakEvent.cs and found that the one line, that checks the parameter, is different from the one in Cinch. After changing the WeakEvent constructor to:

// Cinch V2 (68724)
//if (!argsParameter.ParameterType.IsSubclassOf(typeof(EventArgs)))

// From http://www.codeproject.com/script/Articles/ViewDownloads.aspx?aid=29922
// (FastSmartWeakEvent.cs) Allows type of exactly System.EventArgs
if (!(typeof(EventArgs).IsAssignableFrom(argsParameter.ParameterType)))
throw new ArgumentException("The second delegate parameter must be derived from type 'EventArgs'. Type is " + argsParameter.ParameterType);

the WeakEvent<EventHandler<EventArgs>> works well. I guess this is the intended way (why should EventArgs be avoided?).

Thanks

Robert