Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Calling Windows 10 APIs from a WinForms or WPF application

blogs.windows.com

Post reply on HN
Print view View original

31–40 of 71 posts

Re: Calling Windows 10 APIs from a WinForms or WPF application

#31

Post by ocdtrekkie »

derefr wrote: post #30
nikanj wrote: post #22

Earlier quoted context omitted.

The enterprise market has repeatedly chosen locked-down-and-supported over free-but-you're-on-your-own. This will probably never change.

What would happen if the vendors got together as an organizational body (or their employees as a union/guild) and decided to just not provide the enterprise market with even one locked-down-and-supported option?

Then the one company that either bucks the trend or decides to enter the market after them with a locked down and supported option wins the market by default.

Re: Calling Windows 10 APIs from a WinForms or WPF application

#32

Post by derefr »

ocdtrekkie wrote: post #31
derefr wrote: post #30

Earlier quoted context omitted.

What would happen if the vendors got together as an organizational body (or their employees as a union/guild) and decided to just not provide the enterprise market with even one locked-down-and-supported option?

Then the one company that either bucks the trend or decides to enter the market after them with a locked down and supported option wins the market by default.

Are you imagining a union without any sort of industry-wide enforcement of disbarment for professional malfeasance? That's a pretty nonstandard interpretation of "union."

Re: Calling Windows 10 APIs from a WinForms or WPF application

#33

Post by scandox »

problems wrote: post #29
jug wrote: post #15

Earlier quoted context omitted.

As a mostly C++/.NET dev since over a decade, I've tried to embrace the "modern web" a bit more, but as soon as I did... Web development in 2016 feels comparatively _insane_ to a dev used to structured .NET full stack development in a big IDE made for the purpose, on a platform with slow incremental improvements over the years with a vision and coherence from a single company. It's like assembling a castle from brick…

> There _are_ options for people like me. Angular 2, EmberJS, big hunking frameworks like those. The biggest problem isn't just that, it's that those big frameworks change fairly frequently too. I've witnessed web projects go from backbone to angular to react in the span of a year. I'm mainly a Qt dev, however I needed to add a Cesium component to the application I'm working on. What a mess. Everything about the java…

I haven't found a compelling reason to move away from Backbone yet. It's not perfect, but it does the essentials and it is very stable and well understood.

Might be the relatively reasonable size of the projects I have going. But it works well for a lot of stuff.

I think a lot of the problem comes from fear of projects becoming obsolete. Ultimately JS/CSS/HTML isn't going to fundamentally transform in short order.

Re: Calling Windows 10 APIs from a WinForms or WPF application

#34

Post by augustl »

digi_owl wrote: post #12

As a user i find going the other way more troubling. Say i want to use a UWP file manager on Windows 10. Out of the box the folders i can access are limited, and adding more require that i use the age old Win32 file picker window. Similarly both Google and Mozilla stopped developing a UWP native UI for their web browsers, as it would only be active if the browser was set as the default one. Something that is not alwa…

> Google and Mozilla stopped developing a UWP native UI for their web browsers, as it would only be active if the browser was set as the default

Woha. That is pretty crazy.

Re: Calling Windows 10 APIs from a WinForms or WPF application

#35

Post by Longhanks »

becarefulyo wrote: post #7
diego_moita wrote: post #2

Similar tricks[0] can be used on Win32 applications. Although, I never got Intellisense working in VS if I declare #using in C++/Win32 projects. A simpler and a lot more interesting alternative (for Win32) is the excellent cppwinrt library[1] [0] https://software.intel.com/en-us/articles/using-winrt-apis-f... [1] https://github.com/Microsoft/cppwinrt

The article has Win32 examples too.

Using C++/CX (as seen by ref new).

cppwinrt is ISO C++.

Re: Calling Windows 10 APIs from a WinForms or WPF application

#36

Post by chadgeidel »

floopidydoopidy wrote: post #18
ocdtrekkie wrote: post #17

Earlier quoted context omitted.

Because Microsoft supports critical applications that businesses use for well over ten years in a lot of cases. Zero other operating systems have to provide the platform stability that Microsoft does. So, of course, if they have to focus on supporting only one, archaic platform, they never move forward or create anything new or improved. Which doesn't make sense. So you continue to create newer, better platforms, but…

They only have to provide this because they lock down their products. They do it to themselves.

The open web and open frameworks supporting it have changed significantly over the past 10 years. It's "keep the old stuff running" or "rewrite" there too.

Re: Calling Windows 10 APIs from a WinForms or WPF application

#37

Post by pjmlp »

miguelrochefort wrote: post #14
jmkni wrote: post #9

I absolutely love WPF development. I'm all web now, and I love it too, but sometimes I just wish I could go back to the good old WPF days! The extensive tooling involved with frontend web development and the constant religious wars between frameworks can get exhausting.

Why not port WPF to the web?

I have a better idea, drop JavaScript from Web and leave it as pure HTML/CSS.

Re: Calling Windows 10 APIs from a WinForms or WPF application

#38

Post by contextfree »

jug wrote: post #19
digi_owl wrote: post #12

As a user i find going the other way more troubling. Say i want to use a UWP file manager on Windows 10. Out of the box the folders i can access are limited, and adding more require that i use the age old Win32 file picker window. Similarly both Google and Mozilla stopped developing a UWP native UI for their web browsers, as it would only be active if the browser was set as the default one. Something that is not alwa…

I find UWP pretty terrible. :( It feels like developing for a weakest link (the traditional cross-platform problem) which is often Windows Phone or something. Which doesn't exist!! Windows Phone doesn't bloody exist! If MS had amazing mobile market penetration UWP would be amazing but what is this?! How is UWP exactly better than WPF for Windows desktop apps? It isn't. But it's where MS now wants you to be, because t…

WPF has a dependency on the CLR which made it a non-starter for the Windows and Office teams. That's the main reason WinRT/UWP XAML was developed in the first place; they wanted a developer platform they could use themselves, and those teams are unlikely to adopt C# anytime soon.

Re: Calling Windows 10 APIs from a WinForms or WPF application

#39

Post by pjmlp »

Longhanks wrote: post #35
becarefulyo wrote: post #7

Earlier quoted context omitted.

The article has Win32 examples too.

Using C++/CX (as seen by ref new). cppwinrt is ISO C++.

C++/WinRT is still WIP.

I wouldn't use it for production code until it reaches feature parity with C++/CX.

Re: Calling Windows 10 APIs from a WinForms or WPF application

#40

Post by pjmlp »

contextfree wrote: post #38
jug wrote: post #19

Earlier quoted context omitted.

I find UWP pretty terrible. :( It feels like developing for a weakest link (the traditional cross-platform problem) which is often Windows Phone or something. Which doesn't exist!! Windows Phone doesn't bloody exist! If MS had amazing mobile market penetration UWP would be amazing but what is this?! How is UWP exactly better than WPF for Windows desktop apps? It isn't. But it's where MS now wants you to be, because t…

WPF has a dependency on the CLR which made it a non-starter for the Windows and Office teams. That's the main reason WinRT/UWP XAML was developed in the first place; they wanted a developer platform they could use themselves, and those teams are unlikely to adopt C# anytime soon.

Actually WinRT/UWP are the Longhorn ideas, using the original design of .NET, originally known as COM+ Runtime.

Also a reason why .NET is AOT compiled to native code on UWP.

Post reply on HN