I am consistently experiencing the weirdest thing whenever I use MVVM Light. I create a ViewModelLocator and register in as a static resource in app.xaml:
<viewmodel:WindowsViewModelLocator x:Key="ViewModelLocator" />
Everything works fine, meaning that on launch the static resource is registered, I can use it, and I can see it by going to
App.Current.Resources["ViewModelLocator"]
but then suddenly, randomly, and permanently, this stops working. It has happened to me on every single project, but I'm yet to identify why, as I can't identify the consistent action I did to make it stop working, nor can I figure out any way to revert it back to whatever it was I had when it was working...
the only way to move on is to manually register the resource on startup like this:
if (!Resources.ContainsKey("ViewModelLocator") || Resources["ViewModelLocator"] == null) Resources.Add("ViewModelLocator", new WindowsViewModelLocator());
and finally everything starts working again and usually that's the end of it.
But it happens EVERY SINGLE TIME.
I set a breakpoint in the constructor of the locator and it surely is not being hit... anybody have any idea what I might have possibly done wrong?
EDIT: I finally found the actual exception which was:
A first chance exception of type
'Microsoft.Practices.ServiceLocation.ActivationException' occurred in
GalaSoft.MvvmLight.Extras.DLL
which led me to find the answer which I've posted below. thanks!
It turns out the problem was the order in which I was registering the viewmodels that have dependencies. I have a base ViewModelLocator that initialized the ViewModels, and an inherited ViewModelLocator that contains the Platform-specific code...
In one of the constructors of one of the ViewModels, I was referencing one of the dependent types, which would be registered with a design-time instance. But since this was runtime (which doesn't get registered until it hits the derived platform viewmodellocator) the reference was null.
I moved the dependent code out of the constructor into a more appropriate location and that appears to fix it!
long story short: if you're having this issue, make sure you are initializing everything correctly in the right order and in the right place!
Related
Suppose I have a non-qt object. For example, the QT static-only log handler. How does one cause this file handler to know where to go to look for the current configuration file without, say, hard-coding the application name, organization etc. into the static log-handler function?
I have tried defining a global pointer to the configuration that gets initialized during a startup phase, but this turns out to be a hairy problem to solve during the linking phase. Is there some particular "only-way-is-the-best-way" solution?
(New to QT; if there is an "accepted" or "intended" approach, I would like to take that)
May be create global singleton class?
Or set QSettings::setDefaultFormat() to ini near your binary?
We have a WebForms Control which requires that the ID of another Control implementing ITextControl is provided.
What exception should we throw if there is no control with that ID or a control is found but it's not implementing the interface?
var text = Page.FindControl(TextProviderId) as ITextControl;
if (text == null) {
throw new WhatEverException(...);
...
Should we split it into two cases and throw one exception if there is no control with that ID, and another one if said control does not implement ITextControl? If so, which exceptions should we use then?
If the control should really be there, I would say that your web form is in an invalid state if it is missing, so I would probably go for InvalidOperationException:
The exception that is thrown when a method call is invalid for the object's current state.
This would be applicable to both scenarios; regardless of whether the control is missing or if it does not implement the expected interface, the containing object is in an invalid state.
If this is a scenario that is expected to happen for various reasons (let's say that you are making some tool that others will program against, and this is a situation that they might very well produce), perhaps you should instead create two custom exceptions that make it very clear what is happening and how to correct it (such as ControlNotFoundException and InterfaceNotFoundException or something similar).
ArgumentOutOfRangeException?
Whether or not you should split them up into different exceptions probably depends most on whether or not you think it is likely that anyone will ever want to distinguish the two exceptions in different catch blocks.
Not knowing exactly how this will be used, this seems like the kind of error that should be brought to the developer's attention, where rewriting code to point to the correct file or implement the correct interface is the proper action, rather than implementing a try-catch and give the user friendly error messages. As such, I'd just throw an ArgumentException.
I get the following error in the UDK Frontend when I try to make my project:
C:\UDK\UDK-2010-03\Development\Src\FixIt\Classes\ZInteraction.uc(58) : Error, Accessing a member of GameUISceneClient's within class through a context expression requires explicit 'Outer'
The class ZInteraction extends Interaction.
Line 58 is: GetSceneClient().ConsoleCommand("KEYNAME"#Key);
What is the problem here? I am still investigating and I will update as I find out more.
edit: Tried fixing the line up as class'UIRoot'.static.GetSceneClient().ConsoleCommand("KEYNAME"#Key); - no change.
Found it!
From a forum post, Scripting Changes from UT3:
When accessing a member of a within class' container class, you now have to use the special Outer member variable. This presumably helps deal with name clashes.
I had to change the code to the following:
GetSceneClient().Outer.Outer.ConsoleCommand("KEYNAME"#Key);
Depending on what function is giving you this error, you will need one or more sets of Outer.. You can research to find out how many layers deep you are, or you can just add one at a time until the code compiles. I chose the latter, because it's hard enough already to navigate this UnrealScript. :)
I got a master page with a server control in it. Randomly the server control is inaccessible from codebehind. This doesn't happen on a specific action (eg a Button click or so). Currently I have no clue what this could be. I don't think it's output caching since this is not explcitly activated and the error happens far to seldom for that. But I'm going to disable caching in the master page explicitly with next deployment.
Anyone an idea how to find more info to find what's happening? Or has someone had a similar error?
The control is defined in markup. The accompaning codebehind is:
PGFMainNavi.HasAccessToFunction = HasAccessToNaviItem;
// HasAccessToNavi is a local function
Exception is:
System.NullReferenceException: Object reference not set to an instance
of an object
Thanks.
sa
I have similar errors when I cache my controls - and I always check if their null, or if they are the correct types.
I think that your control is cached somewhere.
Use this code, to check that is not cached.
if(PGFMainNavi != null)
{
PGFMainNavi.HasAccessToFunction = HasAccessToNaviItem;
}
or find where you set the case on this control and remove it.
Second Solution
Some times after an online update I get this error, because compiler did fail to read correct all involving files - probably some user read the page the same time I copy the files or something.
To avoid that I always use the app_offline.htm before make my updates.
I am storing an array of a custom serializable class in session on my site. When a page on the site changes, suddenly it renders them invalid, and tells me that it can't cast the type to it's own type. I assume the class version numbers are changing or something?!
I'd appreciate avoiding the "don't use session" answers, unless it's a really simple solution. I'm not trying to redesign this whole process.
Unable to cast object of type 'ShipmentPackages[]' to type 'ShipmentPackages[]'.
Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: System.InvalidCastException: Unable to cast object of type 'ShipmentPackages[]' to type 'ShipmentPackages[]'.
Source Error:
Line 21: Else
Line 22: If Not Session("ShipmentList") Is Nothing Then
Line 23: ShipmentList = DirectCast(Session("ShipmentList"), ShipmentPackages()).ToList
Line 24: End If
Line 25: End If
I have seen this message a number of times myself, it is very annoying! As you pointed out, it probably because the assembly version changed. In Asp.Net, when the page changes, the code gets recompiled. Depending on where you put the class will determine if the class gets recompiled with the page or not. I would suggest moving any "model" type classes to a separate project. This will avoid this problem as well as the urge to mix view/controller and model code :).
You can also try serializing the object into session as XML. If you do, you should be able to deserialize it even if the assembly changes, though not if the properties on the object change.
I know you said you didn't want to hear this, but you might also consider not putting objects in the session. This makes it difficult to scale your application if the time ever comes that it is necessary. The sooner you fix this the easier it will be to fix.
A few days ago I got annoyed by this issue too. Alas Brian's first solution will only work as long as you do not need to compile the "model-project" again. If you do that (because of a bugfix, etc.) and update the running application (with users holding their session during the update-process, what is done in my case) you get the exception again :-(!
In my special case the best solution was really easy! I changed "DirectCast" to "TryCast". If the assemblyversion changed and casting fails, trycast will return nothing. In this case, or if I haven't written the dictionary/collection to the session yet, I fetch my data (again) over the database and store afterwards. The next time casting will work ;-)! And another great point, this works also if the interface of the object will change!