KeldorKatarn
Topic Author
Posts: 234
Joined: 30 May 2014, 10:26

Re: Caliburn.Noesis (Caliburn.Micro port)

14 Jan 2025, 22:36

I'm having an issue with this code:
        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);
            });
        }
This is the changed event handler of a DependencyProperty. As soon as the handler is executed and is trying to access the closure
var target = e.NewValue;
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:
var target = newValue;
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
 
KeldorKatarn
Topic Author
Posts: 234
Joined: 30 May 2014, 10:26

Re: Caliburn.Noesis (Caliburn.Micro port)

14 Jan 2025, 23:04

Also just to make sure, is this code ok?
        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;
        }
Specifically the creation of RoutedEventArgs with these parameters, since there are is no parameterless constructor?
 
User avatar
jsantos
Site Admin
Posts: 4215
Joined: 20 Jan 2012, 17:18
Contact:

Re: Caliburn.Noesis (Caliburn.Micro port)

14 Jan 2025, 23:59

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.
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
Topic Author
Posts: 234
Joined: 30 May 2014, 10:26

Re: Caliburn.Noesis (Caliburn.Micro port)

15 Jan 2025, 03:33

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.
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.
 
KeldorKatarn
Topic Author
Posts: 234
Joined: 30 May 2014, 10:26

Re: Caliburn.Noesis (Caliburn.Micro port)

15 Jan 2025, 14:05

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.
 
KeldorKatarn
Topic Author
Posts: 234
Joined: 30 May 2014, 10:26

Re: Caliburn.Noesis (Caliburn.Micro port)

16 Jan 2025, 23:35

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.
 
KeldorKatarn
Topic Author
Posts: 234
Joined: 30 May 2014, 10:26

Re: Caliburn.Noesis (Caliburn.Micro port)

22 Jan 2025, 00:46

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.
 
User avatar
jsantos
Site Admin
Posts: 4215
Joined: 20 Jan 2012, 17:18
Contact:

Re: Caliburn.Noesis (Caliburn.Micro port)

23 Jan 2025, 00:30

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.
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.
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.
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.
 
KeldorKatarn
Topic Author
Posts: 234
Joined: 30 May 2014, 10:26

Re: Caliburn.Noesis (Caliburn.Micro port)

23 Jan 2025, 01:00

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.
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.
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.
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