- KeldorKatarn
- Posts: 193
- Joined:
Duplicate call to GUI.LoadComponent?
This is just a question to make 100% sure of something which I already assume:
Calling GUI.LoadComponent(this, "XYZ.FooBar.xaml"); twice on the same user control has absolutely no negative effect. Is that correct?
Because if it is, I can automate this call in Caliburn.Noesis and get rid of the necessity for a code behind file (provided there's no additional logic in there).
I can only do that however if I can make sure that if the user keeps the file I don't break something by calling it twice. Because from what I can tell there's no way
for me to tell if it has already been called.
Edit: Actually... is there a way to get the path to the thing in reflection? so far I used an extension method using [CallerFilePath], but that no longer works if I do this from the outside hm...
In WPF the framework checks if the components are already loaded and bails out of the method of it gets called twice, so Caliburn.Micro can call it twice, no problem.
That allows Caliburn.Micro users to get rid of most of their code behind files.
In Caliburn.Noesis I could achieve the same thing and at the same time get rid of all the mess in the codebehind file necessary for Noesis like having the correct path in there that doesn't break just because the file got moved into a different folder. (I can of course not real with any event handling stuff the user might need, but I could automate the GUI.LoadComponent call,
Calling GUI.LoadComponent(this, "XYZ.FooBar.xaml"); twice on the same user control has absolutely no negative effect. Is that correct?
Because if it is, I can automate this call in Caliburn.Noesis and get rid of the necessity for a code behind file (provided there's no additional logic in there).
I can only do that however if I can make sure that if the user keeps the file I don't break something by calling it twice. Because from what I can tell there's no way
for me to tell if it has already been called.
Edit: Actually... is there a way to get the path to the thing in reflection? so far I used an extension method using [CallerFilePath], but that no longer works if I do this from the outside hm...
In WPF the framework checks if the components are already loaded and bails out of the method of it gets called twice, so Caliburn.Micro can call it twice, no problem.
That allows Caliburn.Micro users to get rid of most of their code behind files.
In Caliburn.Noesis I could achieve the same thing and at the same time get rid of all the mess in the codebehind file necessary for Noesis like having the correct path in there that doesn't break just because the file got moved into a different folder. (I can of course not real with any event handling stuff the user might need, but I could automate the GUI.LoadComponent call,
- KeldorKatarn
- Posts: 193
- Joined:
Re: Duplicate call to GUI.LoadComponent?
Nevermind, there's actually no way for me to get the path to the file outside of it itself. Sigh. This code behind thing is really annoying :P
-
sfernandez
Site Admin
- Posts: 2984
- Joined:
Re: Duplicate call to GUI.LoadComponent?
Correct, that just loads again the xaml and assigns it to the specified object, we internally use it to hot-reload xamls.Calling GUI.LoadComponent(this, "XYZ.FooBar.xaml"); twice on the same user control has absolutely no negative effect. Is that correct?
As you later said, it is not possible from outside the class code. Maybe we can provide a new LoadComponent that uses [CallerFilePath] to automatically generate the path, but I'm not sure if it will be possible. What we had in mind is generating the code-behind for the InitializeComponent, FindNames and ConnectEvents automatically (#1790).is there a way to get the path to the thing in reflection? so far I used an extension method using [CallerFilePath], but that no longer works if I do this from the outside
- KeldorKatarn
- Posts: 193
- Joined:
Re: Duplicate call to GUI.LoadComponent?
Yeah.. the problem with that is that it needs to work like in WPF, putting those .cs files in a folder where Unity finds them, where IDE's understand them, but where they don't clutter the project...
Who is online
Users browsing this forum: Bing [Bot] and 82 guests