PICK and UWP
153 views
Skip to first unread message
Peter McMurray
Nov 17, 2016, 11:56:35 PM11/17/16
to Pick and MultiValue Databases
PICK and UWP
The Pick Database as Dick intended it to be used is a perfect fit for the Microsoft Universal Windows Platform (UWP).
Windows 10 is the managed code implementation of UWP and is so far advanced over earlier versions that any Google posts more than two years old should be viewed with caution.
As Pick devotees we are aware of the power of the database and equally aware that there is no modern UI whereas Microsoft Windows dominates the desktop which is our application domain. There are also several other UI areas that have exploded in the last few years. Mobile phones, IOS, XBox,Holographic, Surface Hub. The UWP allows one code set to address all these areas.
MVSharp has approached the issue from one angle by converting MV Basic to C# thus giving us a massive leap forward using our current expertise.
The languages that interest me particularly are XAML,C# and F# all use the same set of UWP APIs. All available from Visual Studio together with Xamarin forms. Visual Studio now on Apple for those devotees.
XAML is the preferred UI development language. It is not XML albeit that was its genesis along with XOML. It is a powerful primary Microsoft language that handles the View and a good part of the View Model part of MVVM.
The Model in our case being the MV database.
XAML elements map to CLR Objects that map to MV Items.
XAML atributes map to CLR Properties that map to MV Attributes.
XAML StaticResource is similar to MVBasic equates.
The older XOML now part of XAML was close to the Matread and Matwrite definitions in MVBASIC
Complex intermediate code prior to updating the database can be done either in a Microsoft language or in an MV subroutine prior to calling an MVBasic database CRUD routine. In fact the current D3 and probably all the other implementations allow direct Microsoft program interaction with the database but I have never tested that.
One of the major changes is that you can forget pixels as the Visual State on the chosen device is now the focus.
I can immediately see a chance to use XAMARIN forms to transfer orders to and from phones without having to change any of my complex routines in my application.
I already have the attributes defined in a global application dictionary and every file defined using those attributes. XAML can be written in a Pick program just as easily as a CSV file can and is used now. I am more likely to do most of the design in Visual Studio.
My next step is to redesign my standard interface in Xamarin forms, again not too difficult as all my code is standard.
Xamarin Studio is now deprecated in favour of Xamarin on Visual Studio.
XAML Framework written in native code has superceded WPF.
Windows forms is superceded and now in Maintenance mode.
Silverlight has been killed off by HTML5. You can use the latter if you wish but XAML is better.
I look forward to comments expanding the possibilities of the greatest single computing paradigm change in recent times.
Tony Gravagno
Nov 18, 2016, 6:45:38 PM11/18/16
to Pick and MultiValue Databases
Peter, this is an outstanding post! Thank you!!
I've written a lot on this topic over the years and am glad to see the enthusiasm.
I will offer a few notes for anyone who cares to research the topic.
sgML is the parent definition of all MLs.
XML derives from sgML.
xaML, axML, htML, spreadsheetML, and others derive from XML.
Such nuances aren't important but I think it's helpful to know the roots.
Generating XAML isn't quite as easy as CSV, but sure, ultimately one is just building a text block.
XAML has nested structures, opening and closing tags which must be tracked, and a much more rigorous syntax.
Anyone who is inclined to generate XAML from BASIC has been able to do so since the '90s.
The better approach to doing this is with templates where you pull in a pre-defined node of interest and populate it with detail.
But in the context of recent discussions, mobile development, etc. There isn't much need to generate XAML at all.
Usage of XAML is a choice, not so much a requirement. It allows a UI to be hand-crafted or developed visually It's a modern equivalent to drag/drop Windows Forms where there was auto-generated code continually updated as we visually modified the UI.
Once the XAML has been established, it serves more as just a starting point for a running app.
For _dynamic_ UI management we use code. This is where the object model comes in. For example, if you want to put a button on a form you can hard-code XAML something like this:
<page><form><button>...
Or you can do it in code something like this:
var page = new Page() { // params }
var form = new Form() { // params }
var button = new Button() { // params }
form.add(button);
page.add(form);
(contrived names and syntax which is different for various targets, just demonstrating the structure)
In summary on that, skills in both XAML and code are required, but again, how much XAML is used is a choice. This is similar to other languages and frameworks. In ASP.NET we can visually design a page and/or we can do the same thing from code-behind. In PHP we can hardcode HTML and other page components, or we can do it with PHP code.
What we're seeing is that we have many Options. And that brings me to Windows Forms and WPF. I do not believe you will find statements from Microsoft that WinForms or WPF are being superceded, obsolete, etc. As with all technologies, when something new comes around there is a spike in adoption, and older tech goes into maintenance mode. But over several years Microsoft has not followed the common approach to deprecating the old in favor of the new. Rather, they are constantly presenting us with new options, not forcing replacement. MVC does not replace ASP.NET WebForms, it's an alternative. WPF does not replace WinForms. They still support tech that we've considered dead for years. WinForms, WPF, and ASP.NET are all still alive and well in the .NET Framework v4.6. To this they have ADDED options for .NET Core and Xamarin, supporting all of these underneath with the .NET Standard Library.
All that said, yeah, Silverlight is going away, once supported as the answer to a lot of issues but the world has moved on and Silverlight does not represent our collective forward direction.
But as to "XAML is better", please note that XAML was/is core to Silverlight in exactly the same way as it's core to anythig else discussed here. This comes back to a comment I made in another thread that XAML isn't a universal solution in itself, it's merely a definition for layout which is used differently by different platforms. The syntax is consistent but as with any language framework, you'll find the actual object names and properties are all rather different across platforms. Silverlight just had different objects and properties from Xamarin but it's all still XAML.
So I encourage you to shift from looking at all of this as old-to-new, but rather as opportunities to try something new and then to make choices about which tools (together or apart) you feel are better to respond to specific business and technical challenges.
All of this comes back to my mantra over the last couple decades - it doesn't really matter which technologies you adopt, just pick one and move forward. Whether we're talking about Viságe or DesignBais, FlashCONNECT or mv.NET, Osmosis or ASP.NET Webforms, VB.NET or Java, JavaScript or Adobe Flash/Flex. For all of the rhetoric about what's "better", too many companies still haven't done anything. Picking up on any of these and moving forward is far better than waiting for the perfect one that never did come or never will come, all while MV end-users are walking away from their VARs. This is as good a place as any to just hop on the train and go.
Regards,
T
I've written a lot on this topic over the years and am glad to see the enthusiasm.
I will offer a few notes for anyone who cares to research the topic.
sgML is the parent definition of all MLs.
XML derives from sgML.
xaML, axML, htML, spreadsheetML, and others derive from XML.
Such nuances aren't important but I think it's helpful to know the roots.
Generating XAML isn't quite as easy as CSV, but sure, ultimately one is just building a text block.
XAML has nested structures, opening and closing tags which must be tracked, and a much more rigorous syntax.
Anyone who is inclined to generate XAML from BASIC has been able to do so since the '90s.
The better approach to doing this is with templates where you pull in a pre-defined node of interest and populate it with detail.
But in the context of recent discussions, mobile development, etc. There isn't much need to generate XAML at all.
Usage of XAML is a choice, not so much a requirement. It allows a UI to be hand-crafted or developed visually It's a modern equivalent to drag/drop Windows Forms where there was auto-generated code continually updated as we visually modified the UI.
Once the XAML has been established, it serves more as just a starting point for a running app.
For _dynamic_ UI management we use code. This is where the object model comes in. For example, if you want to put a button on a form you can hard-code XAML something like this:
<page><form><button>...
Or you can do it in code something like this:
var page = new Page() { // params }
var form = new Form() { // params }
var button = new Button() { // params }
form.add(button);
page.add(form);
(contrived names and syntax which is different for various targets, just demonstrating the structure)
In summary on that, skills in both XAML and code are required, but again, how much XAML is used is a choice. This is similar to other languages and frameworks. In ASP.NET we can visually design a page and/or we can do the same thing from code-behind. In PHP we can hardcode HTML and other page components, or we can do it with PHP code.
What we're seeing is that we have many Options. And that brings me to Windows Forms and WPF. I do not believe you will find statements from Microsoft that WinForms or WPF are being superceded, obsolete, etc. As with all technologies, when something new comes around there is a spike in adoption, and older tech goes into maintenance mode. But over several years Microsoft has not followed the common approach to deprecating the old in favor of the new. Rather, they are constantly presenting us with new options, not forcing replacement. MVC does not replace ASP.NET WebForms, it's an alternative. WPF does not replace WinForms. They still support tech that we've considered dead for years. WinForms, WPF, and ASP.NET are all still alive and well in the .NET Framework v4.6. To this they have ADDED options for .NET Core and Xamarin, supporting all of these underneath with the .NET Standard Library.
All that said, yeah, Silverlight is going away, once supported as the answer to a lot of issues but the world has moved on and Silverlight does not represent our collective forward direction.
But as to "XAML is better", please note that XAML was/is core to Silverlight in exactly the same way as it's core to anythig else discussed here. This comes back to a comment I made in another thread that XAML isn't a universal solution in itself, it's merely a definition for layout which is used differently by different platforms. The syntax is consistent but as with any language framework, you'll find the actual object names and properties are all rather different across platforms. Silverlight just had different objects and properties from Xamarin but it's all still XAML.
So I encourage you to shift from looking at all of this as old-to-new, but rather as opportunities to try something new and then to make choices about which tools (together or apart) you feel are better to respond to specific business and technical challenges.
All of this comes back to my mantra over the last couple decades - it doesn't really matter which technologies you adopt, just pick one and move forward. Whether we're talking about Viságe or DesignBais, FlashCONNECT or mv.NET, Osmosis or ASP.NET Webforms, VB.NET or Java, JavaScript or Adobe Flash/Flex. For all of the rhetoric about what's "better", too many companies still haven't done anything. Picking up on any of these and moving forward is far better than waiting for the perfect one that never did come or never will come, all while MV end-users are walking away from their VARs. This is as good a place as any to just hop on the train and go.
Regards,
T
geneb
Nov 19, 2016, 11:34:30 AM11/19/16
to Pick and MultiValue Databases
> var page = new Page() { // params }
> var form = new Form() { // params }
> var button = new Button() { // params }
While technically legal, "var" is wrong. (to me) :)
> var form = new Form() { // params }
> var button = new Button() { // params }
As far as I'm concerned, "var" is more accurately described as "meh". :)
Page page = new Page();
Form form = new Form();
Button button = new Button();
Fixed that for ya. :D
g.
--
Proud owner of F-15C 80-0007
http://www.f15sim.com - The only one of its kind.
http://www.diy-cockpits.org/coll - Go Collimated or Go Home.
Some people collect things for a hobby. Geeks collect hobbies.
ScarletDME - The red hot Data Management Environment
A Multi-Value database for the masses, not the classes.
http://scarlet.deltasoft.com - Get it _today_!
Tony Gravagno
Nov 21, 2016, 4:39:00 PM11/21/16
to Pick and MultiValue Databases
geneb wrote:
While technically legal, "var" is wrong. (to me) :)
Fixed that for ya. :D
( Huge smiley noted but... )
You missed "(contrived names and syntax which is different for various targets, just demonstrating the structure)"
And, actually, no. It's not just "technically legal".
"var" is valid, current for C#, extremely common, and does not lead to confusion or type issues.
Your qualifiers "(to me)" and "As far as I'm concerned" are noted, but opinions on contrived syntax only serve to detract from the main point. You might as well have suggested that getting objects from "new" should have been replaced by a factory.
If you want to get pedantic about it, try this:
var page = getPage();
var form = getForm();
var button = getButton();
In this case you don't know that page is of type Page, it might be a type that implements IPage, or a derived type of an abstract or concrete Page. Declaring Page leaves you with a hard-coded type that might not be what you want, forcing later casting like ((MyPage)page).doSomething().
Discussion on polymophism is plentiful elsewhere and only serves here to erode on-topic exhanges.
The POINT was that XAML is optional, not a requirement, and that it can be replaced in many contexts with code that defines UI structure.
Best,
T
Peter McMurray
Nov 22, 2016, 3:14:00 PM11/22/16
to Pick and MultiValue Databases
TG's point is perfectly correct
"The POINT was that XAML is optional, not a requirement, and that it can be replaced in many contexts with code that defines UI structure."
However if you wish to gain maximum advantage from UWP. XAML, MVVM and XAMARIN are essential development routes together with the languages of your choice.
Mention has been made of CORE, ASP.NET Core in particular. This is a subset of UWP that contains only the parts directly relevant to the particular target. If one uses the full UWP then the store release will deliver the CORE relevant to your app on the equipment it is purchased for. So using the full UWP is, in my opinion, preferable. Of course people who have spent a deal of effort learning a particular method may have to change slowly.
In another thread Chandru mentioned the dreaded pinch on phones. People need to be aware and design the XAML for the overall package with common code behind and just a small segment relevant to the final display.
"Developing Windows 10 Applications with C#" by Sergeii Baidachnyi and Petzold's book on XAMARIN are excellent starting points in conjunction with products such as MVSP which is part of D3. I want to use the MV database because I know it is great. I am happy with green screen because it works well for operators but customers want to see the latest whizzbang so give it to them gently. Do a piece at a time. Phone delivery entries by the driver should be good to slot in. I remember Mark Brown doing a mug shot application for the police many years ago. Ints Tumolovics did a terrific legal system that incorporated all the relevant parts of a case from witness statements to pictures. Imagine how much easier these would be today.Tony Gravagno
Nov 22, 2016, 10:17:14 PM11/22/16
to Pick and MultiValue Databases
I'm sure you recall the discussions about real mobile apps versus HTML5.
This is exactly what I was talking about back then. The concepts and approaches are just as relevant now as they were then. Each technology has its place. But the tools you're describing are essentially the same as what we had at that time, not so long ago.
The difference now of course is that you've found this stuff on your own. Cuz when it comes from me I totally understand that people just don't want to hear it. ROFL
My model has traditionally been to research and discuss technology in the hope that others with clients and apps would connect the dots and then come to me to build bridges. That's never quite worked well enough, so these days I'm less focused on suggesting solutions to other developers and more interested in the consumer market - the people who directly pay for product and services. As you said "customers want to see the latest whizzbang". That's true. So that's what I try to do with these tools - build things that They want and that They can use, not try to convince others that there are people who want these things. Discussions like this in the MV world are fun and all, but when it comes down to it, unless we as an industry actually take it to the next step and do something with the technology __ when consumers will actually pay for it __ then it's all fairly academic.
T
This is exactly what I was talking about back then. The concepts and approaches are just as relevant now as they were then. Each technology has its place. But the tools you're describing are essentially the same as what we had at that time, not so long ago.
The difference now of course is that you've found this stuff on your own. Cuz when it comes from me I totally understand that people just don't want to hear it. ROFL
My model has traditionally been to research and discuss technology in the hope that others with clients and apps would connect the dots and then come to me to build bridges. That's never quite worked well enough, so these days I'm less focused on suggesting solutions to other developers and more interested in the consumer market - the people who directly pay for product and services. As you said "customers want to see the latest whizzbang". That's true. So that's what I try to do with these tools - build things that They want and that They can use, not try to convince others that there are people who want these things. Discussions like this in the MV world are fun and all, but when it comes down to it, unless we as an industry actually take it to the next step and do something with the technology __ when consumers will actually pay for it __ then it's all fairly academic.
T
Reply all
Reply to author
Forward
0 new messages