[TaskEditor] What about UWP? about taskscheduler

[dahall]

I have started a UWP project based on the TaskOptionsEditor. It will take some time though as it is a decent learning curve for me. If anyone has some good experience with UWP, I'd appreciate collaborating on it.

[scout208]

@dahall Have you still been working on this? I could see both TaskScheduler and TaskEditor being useful in UWP if there was some way to figure that out.

[dahall]

I have the TaskScheduler project now working with all .NET Core versions. I have most of the TaskEditor control done in UWP, but that is the only control. If you have UWP experience, I'd appreciate the help. I'm struggling with some custom controls I need to make.

[scout208]

@dahall Yeah I have a lot of UWP experience, I'd love to help. I haven't done much with WPF though so any sort of transition stuff I might not be able to help with as much.

[dahall]

I'll get all my work on the main library posted so you can use it. If you have ideas on adding the UWP editor, please share here. If you write some code, please share here or in a PR.

[dahall]

@scout208 I just posted 2.8.19 which has support for .NET Core. I think the full task editor is the most important and most used. Have you seen the TaskOptionsEditor? I think that flow is more UWP-like.

[dahall]

@scout208 Having done some online research, I think the page layout of TaskOptionsEditor is good, but using a Pivot control on top instead of the one to the left. Thoughts?

[scout208]

@dahall Yeah, I'm looking at it in the designer now. Based on what it looks like here I'd say a SplitView might be better. By the way, have you installed the Xaml Controls Gallery app? I think it's a great way to play around with and explore a lot of different XAML controls. You can get it from the Microsoft Store if you haven't already.

[scout208]

@dahall There's also the NavigationView control you might want to take a look at.

[dahall]

@scout208 I've been looking at XAML and what it takes to design a good app. Its seems that some sort of MVVM approach has benefits. Which design pattern have you found best? Is there a framework you prefer?

From a control standpoint, I think I have that narrowed down. I have a screenshot of the "Task Scheduler" app that I'll markup with my notes and post them here later today.

[dahall]

@scout208 Here's what I think the control base would employ. Thoughts?

[dahall]

After trying to make a test app work, I have found that the underlying COM objects used to interact with the Windows Task Scheduler are not supported under UWP. So, it appears that we have two options:

1. Develop controls in XAML using WPF and then have UWP developers use Windows Bridge to use them.
2. Force developers to pick side-loading as the only deployment model and use Brokered Windows Runtime Components for side-loaded Windows Store apps to load the COM objects.

Personally, I think option 1 is the only viable solution. What do you think?

[scout208]

I agree with you. I think that there will be some unification of Win32 and UWP in the near future. It seems like Microsoft is trying to get rid of the concept of "Win32 apps" and "UWP apps" and just have "windows apps". See Project Reunion. I don't know exactly what this will mean but I would think it would make it easier to use WPF controls in UWP apps eventually, so keeping the controls the same might not be such a bad idea with that in mind.

[albefly]

dahall, scout208 - thank you for your effort!
As I understand, you can use Win32 / WinForms apps as well for the Bridging, so it is not absolutely necessary to use WPF.
Not sure will it reduce development time or not.

Best regards,
Alex.