-
- KeldorKatarn
- Posts: 234
- Joined:
Re: Caliburn.Noesis (Caliburn.Micro port)
I'm having an issue with this code:
This is the changed event handler of a DependencyProperty. As soon as the handler is executed and is trying to access the closure
Unity crashes. Is there an issue with capturing the DependencyPropertyChangedEventArgs like this? is it crashing because the native pointer has become invalid?
Edit: I've tested this. If I change the code so I cache e.NewValue in a variable and instead do this in the lamda:
it works. So this might be a problem. DependencyPropertyChangedEventArgs are not capturable in a closure? I can work around it in this case, but I need to dig through the code whether this is done anywhere else.
I think this is a bug. I reported it.
https://www.noesisengine.com/bugs/view.php?id=3901
Code: Select all
static void ModelChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
{
if (View.InDesignMode || object.ReferenceEquals(e.NewValue, e.OldValue))
{
return;
}
var fe = d as FrameworkElement;
if (fe == null)
{
return;
}
View.ExecuteOnLoad(fe, delegate
{
var target = e.NewValue;
d.SetValue(View.IsScopeRootProperty, true);
var context = string.IsNullOrEmpty(fe.Name)
? fe.GetHashCode().ToString()
: fe.Name;
ViewModelBinder.Bind(target, d, context);
});
}
Code: Select all
var target = e.NewValue;
Edit: I've tested this. If I change the code so I cache e.NewValue in a variable and instead do this in the lamda:
Code: Select all
var target = newValue;
I think this is a bug. I reported it.
https://www.noesisengine.com/bugs/view.php?id=3901
-
- KeldorKatarn
- Posts: 234
- Joined:
Re: Caliburn.Noesis (Caliburn.Micro port)
Also just to make sure, is this code ok?
Specifically the creation of RoutedEventArgs with these parameters, since there are is no parameterless constructor?
Code: Select all
public static bool ExecuteOnLoad(FrameworkElement element, RoutedEventHandler handler)
{
if (element.IsLoaded)
{
#if UNITY_5_5_OR_NEWER
handler(element, new RoutedEventArgs(FrameworkElement.LoadedEvent, element));
#else
handler(element, new RoutedEventArgs());
#endif
return true;
}
RoutedEventHandler loaded = null;
loaded = (s, e) => {
element.Loaded -= loaded;
handler(s, e);
};
element.Loaded += loaded;
return false;
}
Re: Caliburn.Noesis (Caliburn.Micro port)
We also have this metaticket for Caliburn.Noesis. Please, let us know if there is something critical in that list and feel free to add more tickets to it.If you need anything that is missing in the core triggers from WPF API please create a ticket in our bugtracker and we will fix it.
-
- KeldorKatarn
- Posts: 234
- Joined:
Re: Caliburn.Noesis (Caliburn.Micro port)
Not at the moment. Most of the ones left open are only needed for the extensions I'm planning, not for the core of Caliburn. As I said, aside from this crash caused by the closure, everything seems to be working perfectly now.We also have this metaticket for Caliburn.Noesis. Please, let us know if there is something critical in that list and feel free to add more tickets to it.
-
- KeldorKatarn
- Posts: 234
- Joined:
Re: Caliburn.Noesis (Caliburn.Micro port)
Currently there seems to be one final issue in regards to allowing me to support the dialog functionality:
https://www.noesisengine.com/bugs/view.php?id=3902
For some reason trying to derive from AdornerDecorator and trying to access the AdornerLayer inside that derived class causes a crash.
The code is in the bug report. Not sure what I'm doing wrong.
Also a slight inconsistency with WPF: GetAdornerLayer() should be a property called AdornerLayer, but that's not the problem. Calling GetAdornerLayer() causes a crash.
I have a workaround for this. But I'd still like to know why this happens. If we can confirm that this is an issue I can avoid, then I think Caliburn is ready and I will start towards the first release.
I probably need to make a net472 nuget package for the Blend project as well, so I'll set that up. As before, the code definitely works in both scenarios.
I'll fully test all caliburn features over the rest of the weak and make some samples and document the differences in initial configuration compared to Caliburn.Micro.
But so far everything seems to be working.
https://www.noesisengine.com/bugs/view.php?id=3902
For some reason trying to derive from AdornerDecorator and trying to access the AdornerLayer inside that derived class causes a crash.
The code is in the bug report. Not sure what I'm doing wrong.
Also a slight inconsistency with WPF: GetAdornerLayer() should be a property called AdornerLayer, but that's not the problem. Calling GetAdornerLayer() causes a crash.
I have a workaround for this. But I'd still like to know why this happens. If we can confirm that this is an issue I can avoid, then I think Caliburn is ready and I will start towards the first release.
I probably need to make a net472 nuget package for the Blend project as well, so I'll set that up. As before, the code definitely works in both scenarios.
I'll fully test all caliburn features over the rest of the weak and make some samples and document the differences in initial configuration compared to Caliburn.Micro.
But so far everything seems to be working.
-
- KeldorKatarn
- Posts: 234
- Joined:
Re: Caliburn.Noesis (Caliburn.Micro port)
Ok with the current last issues having been dealt with by workaround, here's the first beta release:
Install in the Unity Package Manager via https://github.com/VacuumBreather/Calib ... urn.Noesis
A sample is included, however for it to work, the package needs to be moved from Library/PackageCache to the actual Packages/ folder as an embedded package since the sample references a ResourceDictionary and that can't be done in the PackageCache yet. Otherwise, all features should be working, and I'll look into documenting and more feature samples over the coming days to move towards a 1.0.0 release.
Install in the Unity Package Manager via https://github.com/VacuumBreather/Calib ... urn.Noesis
A sample is included, however for it to work, the package needs to be moved from Library/PackageCache to the actual Packages/ folder as an embedded package since the sample references a ResourceDictionary and that can't be done in the PackageCache yet. Otherwise, all features should be working, and I'll look into documenting and more feature samples over the coming days to move towards a 1.0.0 release.
-
- KeldorKatarn
- Posts: 234
- Joined:
Re: Caliburn.Noesis (Caliburn.Micro port)
Further updates: I'm in contact with the maintainer of the official Caliburn.Micro repo and we're discussing if the port can be included in the official Caliburn.Micro somehow.
The Unity folder structure and the fact that we need a more Noesis-blend specific version of the WPF nuget package makes that a bit non-trivial however. We'll see how that works out.
The Unity folder structure and the fact that we need a more Noesis-blend specific version of the WPF nuget package makes that a bit non-trivial however. We'll see how that works out.
Re: Caliburn.Noesis (Caliburn.Micro port)
I am not sure to be following why you need to reference the PackageCache folder... Why can't you do the same as our examples and reference the dictionary using the standard /Packages/com.noesis.noesisgui/... syntax.A sample is included, however for it to work, the package needs to be moved from Library/PackageCache to the actual Packages/ folder as an embedded package since the sample references a ResourceDictionary and that can't be done in the PackageCache yet. Otherwise, all features should be working, and I'll look into documenting and more feature samples over the coming days to move towards a 1.0.0 release.
This is awesome news! Don't you think maybe it is easier going with the C# SDK instead of Unity? We have a nuget for noesis.Further updates: I'm in contact with the maintainer of the official Caliburn.Micro repo and we're discussing if the port can be included in the official Caliburn.Micro somehow.
-
- KeldorKatarn
- Posts: 234
- Joined:
Re: Caliburn.Noesis (Caliburn.Micro port)
Well the bootstrapper needs to be a MonoBehavior, otherwise it cannot work in Unity. Unless you mean for Caliburn.Micro official. Yes I've suggested that to them.This is awesome news! Don't you think maybe it is easier going with the C# SDK instead of Unity? We have a nuget for noesis.Further updates: I'm in contact with the maintainer of the official Caliburn.Micro repo and we're discussing if the port can be included in the official Caliburn.Micro somehow.
MIght be easier than having Caliburn.Micro go Unity. The SDK should be more feasable with my port staying in sync with it for Unity.
Maybe we can even combine some stuff.
Who is online
Users browsing this forum: No registered users and 7 guests