Newsgroup: it.comp.dotnet
Titolo: [WPF] System.ArgumentNullException was unhandled...

"Value cannot be null.
Parameter name: d"
Questo ï¿œ quanto mi viene detto dalla mia applicazione WPF che va in 
crash quando cambio la selezione in alcune comboboxes facenti parte di 
un datatemplate utilizzato da alcune foglie di una treeview, e il crash 
ï¿œ randomico.
Il datatemplate ï¿œ selezionato da un datatemplateselector che lo sceglie 
a seconda del type del viewmodel passato al selector come parametro.
Ovviamente non ci sono errori macroscopici, e non riesco a beccare in 
debug il punto di crash (l'ho seguito per mezza giornata) e purtroppo la 
call stack ï¿œ vuota.
Da quanto si dice qui:
http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/fb4d0f41-bfea-409f-b8ac-e66558984b7a
parrebbe un problema del .net4, ma onestamente, anche dopo aver letto 
tutta la storia, non so trovare un workaround e da quanto ho capito 
neanche gli altri.
Vi ï¿œ mai capitato qualcosa di simile? Come mi suggerite di procedere?
Aggiungo sotto la stack trace:
    at MS.Internal.Data.ElementObjectRef.GetObject(DependencyObject d, 
ObjectRefArgs args)
    at MS.Internal.Data.ObjectRef.GetDataObject(DependencyObject d, 
ObjectRefArgs args)
    at 
System.Windows.Data.BindingExpression.MS.Internal.Data.IDataBindEngineClient.VerifySourceReference(Boolean 
lastChance)
    at MS.Internal.Data.DataBindEngine.Task.Run(Boolean lastChance)
    at MS.Internal.Data.DataBindEngine.Run(Object arg)
    at 
System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate 
callback, Object args, Int32 numArgs)
    at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object 
source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)
    at System.Windows.Threading.DispatcherOperation.InvokeImpl()
    at 
System.Windows.Threading.DispatcherOperation.InvokeInSecurityContext(Object 
state)
    at System.Threading.ExecutionContext.runTryCode(Object userData)
    at 
System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode 
code, CleanupCode backoutCode, Object userData)
    at System.Threading.ExecutionContext.RunInternal(ExecutionContext 
executionContext, ContextCallback callback, Object state)
    at System.Threading.ExecutionContext.Run(ExecutionContext 
executionContext, ContextCallback callback, Object state, Boolean 
ignoreSyncCtx)
    at System.Threading.ExecutionContext.Run(ExecutionContext 
executionContext, ContextCallback callback, Object state)
    at System.Windows.Threading.DispatcherOperation.Invoke()
    at System.Windows.Threading.Dispatcher.ProcessQueue()
    at System.Windows.Threading.Dispatcher.WndProcHook(IntPtr hwnd, 
Int32 msg, IntPtr wParam, IntPtr lParam, Boolean& handled)
    at MS.Win32.HwndWrapper.WndProc(IntPtr hwnd, Int32 msg, IntPtr 
wParam, IntPtr lParam, Boolean& handled)
    at MS.Win32.HwndSubclass.DispatcherCallbackOperation(Object o)
    at 
System.Windows.Threading.ExceptionWrapper.InternalRealCall(Delegate 
callback, Object args, Int32 numArgs)
    at MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Object 
source, Delegate method, Object args, Int32 numArgs, Delegate catchHandler)
    at System.Windows.Threading.Dispatcher.InvokeImpl(DispatcherPriority 
priority, TimeSpan timeout, Delegate method, Object args, Int32 numArgs)
    at MS.Win32.HwndSubclass.SubclassWndProc(IntPtr hwnd, Int32 msg, 
IntPtr wParam, IntPtr lParam)
    at MS.Win32.UnsafeNativeMethods.DispatchMessage(MSG& msg)
    at System.Windows.Threading.Dispatcher.PushFrameImpl(DispatcherFrame 
frame)
    at System.Windows.Threading.Dispatcher.PushFrame(DispatcherFrame frame)
    at System.Windows.Threading.Dispatcher.Run()
    at System.Windows.Application.RunDispatcher(Object ignore)
    at System.Windows.Application.RunInternal(Window window)
    at System.Windows.Application.Run(Window window)
    at System.Windows.Application.Run()
    at SpeechVillage.SpeechDraw.SpeechDraw.Main() in 
D:\Documenti\***********\Visual Studio 
2010\Projects\**********\obj\x86\Debug\**********.g.cs:line 50
    at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, 
String[] args)
    at System.AppDomain.ExecuteAssembly(String assemblyFile, Evidence 
assemblySecurity, String[] args)
    at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
    at System.Threading.ThreadHelper.ThreadStart_Context(Object state)
    at System.Threading.ExecutionContext.Run(ExecutionContext 
executionContext, ContextCallback callback, Object state, Boolean 
ignoreSyncCtx)
    at System.Threading.ExecutionContext.Run(ExecutionContext 
executionContext, ContextCallback callback, Object state)
    at System.Threading.ThreadHelper.ThreadStart()

 Vi mai capitato qualcosa di simile? Come mi suggerite di procedere?
Ne so veramente poco di WPF. Mi puoi far vedere qualche riga di codice
su come definisci il binding?
Dalla lettura del thread che hai linkato mi pare di capire che la
definizione del binding viene memorizzata sotto forma di expression,
non c'e' invocazione immediata: questo puo' far si' che quando poi il
binding viene effettivamente applicato, la logica dell'expression
viene eseguita ma l'oggetto sorgente non esiste piu' (o non e' mai
esistito), da cui l'eccezione.
Ammesso che quanto dico sopra abbia qualche senso, la soluzione
sarebbe assicurarsi che gli oggetti sorgente esistono a binding-time,
il che si risolve nell'istanziarli in un appropriato scope...
-LV

 il che si risolve nell'istanziarli in un appropriato scope...
per quanto riesco a debuggare, _children non diventa mai null, dunque 
c'è qualcosa sotto nel meccanismo di binding che supera le mie 
conoscenze/possibilità di capire... ma non pretendo tanto, mi basterebbe 
che la microsoft consigliasse un maledetto workaround nell'attesa di un 
fix (tanto la mia deadline si sposta in continuazione... credo che 
faranno prima loro ;)
Intanto grazie per la risposta!

 Intanto grazie per la risposta!
In bocca al bruco! :)
-LV


Yo, giusto per, visto che il problema in questione davvero mi
interessa: la mia qui era una domanda vera.
Intanto aggiungerei (rettificherei) che il comportamento pseudo-
randomico in realta' puo' avere senso, se il problema e' legato alla
garbage collection...
-LV


 garbage collection...
Dunque, riassumendo il mio albero si appoggia su due viewmodel:
1) il primo che chiamo ResponseEditorViewModel e implementa una classe 
astratta TreeViewViewModel che modella il "contenitore", con una 
property TreeViewItemsVMCollection "creata" cosě:
_treeViewItemsVMCollection = 
GetNodeCollectionFromApplicationContext(currentApplication);
la GetNodeCollectionFromApplicationContext ritorna una
ObservableCollection<ITreeViewItemViewModel> list = new 
ObservableCollection<ITreeViewItemViewModel>();
2) gli altri viewmodel modellano i nodi degli alberi, e implementano 
l'interfaccia che fornisce la property Children. Nello specifico, il 
viewmodel che modella le foglie il cui refresh fa crashare 
l'applicazione si chiama ActionFieldViewModel, e "crea" i children cosě:
public ActionFieldViewModel(ActionViewModel avm, ILogger logger, 
Application app)
{
	//avm č il parent	
	App = app;
	Initialize(avm, logger);
}
private void Initialize(ActionViewModel avm, ILogger logger)
{
	//[...]
	InitTreeViewItemViewModel(avm);
}
public void InitTreeViewItemViewModel(ActionViewModel avm)
{
	_parent = avm;
	_children = new 
ObservableCollection<ITreeViewItemViewModel>(BuildActionFieldChildrenList());
	//[...]
}
Da quanto dicono nel forum il problema sembra effettivamente legato alla 
garbage collection, in aggiunta al fatto che rispetto al .net 3.5 la 
gestione della verifica dei "binding source" nel .net 4 č fatta da un 
task apposito (per quello che ho capito).
Sul problema che č alla radice del bug, su Connect dicono "fixed", ma 
non ci sono link:
http://connect.microsoft.com/VisualStudio/feedback/details/561752/datagrid-crash-when-applying-scaletransform-to-datagridcell#details
(ci si entra solo una volta loggati)

 (ci si entra solo una volta loggati)
Si', ho visto: suppongo che il fatto che lo diano per solved ma non
forniscono un work-around o altro significa che a breve rilasceranno
una patch...
Insomma, avevi ragione a confidare che i cicli di rilascio dei sistemi
operativi sono oggi piu' rapidi di quelli di rilascio dei software
applicativi! ;)
Un ri-in bocca al lupo,
-LV

 Vi è mai capitato qualcosa di simile? Come mi suggerite di procedere?
in questi giorni è uscito un hotfix per .net4 che corregge il problema:
ecco il link:
http://support.microsoft.com/kb/2461678
o più direttamente:
http://connect.microsoft.com/VisualStudio/Downloads/DownloadDetails.aspx?DownloadID=33315
urrà! ciao