|
Dar Brett wrote: Last thought that comes to mind, have you considered getting a Mac?
 Thank you for the chuckle!
|
|
|
|
|
An app I'm working on needs to disable the option to pin the app to the Start and Taskbar. Why? Security concerns. I know, right?!
OK, dig into Google to find out what's involved.
Hmmmm... not much on this except for Raymond Chen's blog post on it with a tiny little C snippet that does it, and the WindowsAPICodePack.
Aight. The codepack is HUGE for what I need it for. One of the restrictions on my app is to make the resulting .EXE as small as possible. The codepack weighs in at almost 700K. This is not an option for an app that has to stay small.
Next option. Write up Raymond's code into a tiny little C++ CLI library and just reference that from the main app.
Crap! Can't do that either. The C++ library targets Win32, not straight-up IL. This is a problem because I also need to keep the app as a single .EXE file with no external .DLL's. To do this, I use ILMerge as a post-build step to roll in my library .DLLs, but it won't throw a Win32 .DLL into a .NET .EXE (and still work.)
Soooooo.... last option. Get the source for the WindowsAPICodePack and strip it down to the ... HOLY ELEPHANTING HELL! Over 50,000 lines of code in this thing! [mutters to self] Is there any part of Windows this thing doesn't wrap?
OK, start digging through and learning the code base. It turns out the thing is nicely organized, but every class is seemingly dependent on every other class. Apparently, complexity was a design requirement. Basically, this library is a massive pile of manually written COM-interop without all the automated helpers Visual Studio and the tools generates for you when you add a reference to a COM .DLL. All this work is necessary because the Windows .DLL that handles this, PropSys.dll, is not COM-exposed.
It took me two days, and a bunch of ![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif) , to slash and burn the code like a Brazilian rain forest with the final result down to about 100 lines of code and a 19K .DLL that ILMerge can deal with. With a bit more time I don't have, I can make it smaller.
Three days to remove one little option on the Taskbar.
|
|
|
|
|
Do an article, or tip to make it easier for the rest of us!
(Pretty please with sugar on?)
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
I might be able to get to it, sometime in 1Q2020. 
|
|
|
|
|
That's only 2 months away!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
we will patiently wait for it   
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
|
Would it have been an option to embed the Win32 DLL as a resource in your exe and extract it at runtime?
Phil
The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.
|
|
|
|
|
I tossed that around for a bit. I can't leave the .DLL behind, so I would have had to do the whole LoadLibrary thing in a separate AppDomain, make the call, unload the AppDomain, then delete the .DLL. Messy.
|
|
|
|
|
My opinion is right for me, but it may not be right for you. But your opinion would be useful.
The Windows Form Designer, from the VB days to Visual Studio 2019 and .NET Framework 4.8 is an amazingly productive tool. The time it takes to build a window like I want, create to the code skeleton for events, etc. is drastically reduced from hand-coding. Thus, in a given amount of project time, I now have more time to spend improving the project, doing more testing, or even adding features. Those things would not be possible without the Designer.
Now, consider XAML Forms and HTML pages for Blazor. No designer. Even a Windows Forms designer in .NET Core 3.0 is missing, for now. Adding those designers would have the same effects for those environments and productivity that the Forms Designer did for VB and Visual Studio.
Microsoft's team of millennials and Gen-Z'ers appear to not have the depth of experience, or concepts of value engineering, to know why a GUI designer is so valuable.
That said, what are your opinions of how important it is to have Xamarin XAML and Blazor HTML designers on a par with the .NET Framework Windows Forms Designer?
|
|
|
|
|
MSBassSinger wrote: HTML designers
Years ago I stopped doing web forms in Design mode because it didn't do a good job generating the html.
But generally speaking, yes, I think the designer can make things much quicker.
Social Media - A platform that makes it easier for the crazies to find each other.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
Pretty much won't touch Xamarin XAML because of the lack of a designer. Won't touch WPF because it lacks a usable designer. While I'm stuck with HTML, tools that let you do side-by-side HTML with preview mitigate the pain.
And yes, very important. I remember when I came out with MyXaml and almost everyone (some rather nastily) said they'd never use a UI generator where you had to edit the "markup" by hand.
And guess where we are now? And guess what camp I'm in when it comes lack of designers. 
That said, if I can avoid having to even touch HTML, the happier I am. I don't mind writing HTML generators (usually client-side on the fly) that create the HTML from some metadata format. But that's me.
|
|
|
|
|
Marc Clifton wrote: Won't touch WPF because it lacks a usable designer
For what it's worth Marc, it's not that hard. I've been doing WPF UI's for over ten years now. WPF 'design' in XAML lends itself well to a top-down, organization first then detail approach.
Software Zen: delete this;
|
|
|
|
|
of the three UI's supported by dotnet; my level of productivity is quickest with Winforms, followed by UWP, and lastly is WPF. WPF for me is just not as "discoverable" as the other two formats, even when using Blend.
|
|
|
|
|
Matt McGuire wrote: Blend
I've never been able to use Blend. It only has a "dark" user interface (even the so-called light theme is gray over darker gray) and is unusable to my middle-aged vision.
Software Zen: delete this;
|
|
|
|
|
I use the XAML designer with WPF, but only to see what the resulting layout is. I do the XAML by hand as I don't like some of the things the designer does when using it's ability to drag and drop or move things around.
It would be nice if VSCode had a visual designer, I think it would make the process quicker.
|
|
|
|
|
I agree, the designer is nice to see how your product is building but had issues in the old asp.net days with it doing some weird things in the raw html.
|
|
|
|
|
As someone who once used FrontPage[^] and Visual InterDev 97[^], all I can say with regards to WSYWIG HTML editors is: never again.
They make it really easy to design things that work on your precise screen resolution, which then fall apart the moment someone resizes the browser window by 10px.
The same thing applied to the WPF designed the last time I tried that.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Richard Deeming wrote: The same thing applied to the WPF designed the last time I tried that.
Which is why I do the XAML by hand, but use the designer to see how it would look like.
The problem with that specific designer is that it creates absolute layouts, instead of relative.
|
|
|
|
|
MSBassSinger wrote: The Windows Form Designer, from the VB days to Visual Studio 2019 and .NET Framework 4.8 is an amazingly productive tool. The time it takes to build a window like I want, create to the code skeleton for events, etc. is drastically reduced from hand-coding.
Long time WinForm user here, and I'm quicker without the designer. "Click, go to properties, undock, move, paste in new panel, redock".
Also seen to many people draw dialogs, with a panel docked to the bottom, containing a panel docked to the right, containing two buttons returning either DialogResult.OK or DialogResult.Cancel. Forms do support inheritance, so you code it once and stop drawing. Has the added advantage that when you want to change the dialogs to have menu's instead of buttons (or whatever), you simply change the base.
So, it may seem a productivity-booster, and it is - for quick and dirty prototyping.
Similarly, you can use databinding from the designer and create working applications. The drawback is that your form doesn't update during processing - so I'll be writing code to do so on a backgroundworker, giving feedback to the user with a progressbar. No databinding here
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I personally avoid those that don't have the designers. Sometimes I cannot remember how to do something or I want quick and dirty. Those designers work wonderfully for each of those things. I can visually "draw" it on the screen and then go look and see how it was built. It ends up being faster than the same google search. I am probably in the minority though.
To err is human to really mess up you need a computer
|
|
|
|
|
The WinForms designer is not without faults (derive a control from an abstract UserControl base and start swearing for example) but by heck it makes life easier!
That's one of the things that - still - makes WPF feel "unfinished" and somewhat amateur to me. If you can do it for C# code, why the heck not do it for more organised and structured XML?
I was looking forward to Blazor but you do need a good designer to give you a WYSWYG "starter" or you waste too much effort before you can start to work on the actual "working stuff".
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: That's one of the things that - still - makes WPF feel "unfinished" and somewhat amateur to me. If you can do it for C# code, why the heck not do it for more organised and structured XML?
Have you looked at the crappy XML based designer for SSRS. Access was far more powerful and easy to use. This is probably why MS hasn't built a decent designer for XML based UIs.
|
|
|
|
|
I thought all my birthdays had come at once, when I started using the VS.NET designer. Writing UI code to cope with resizing, docking and so on used to drive me mad.
|
|
|
|
|
Quote: Microsoft's team of millennials and Gen-Z'ers appear to not have the depth of experience, or concepts of value engineering, to know why a GUI designer is so valuable.
There is a lot of regression taking place all over Microsoft's products (think also for most of the other IT companies). It comes from these same people. They are all self centered in addition to what you have observed, and as a result have no clue how people are actually using their software.
Email is a prime example. The usability is degrading due to Fort Knox security requirement they impose on everything regardless if the user needs it.
Cannot travel anywhere away from my office to trigger a whole series concerned emails and requirements to keep using my email. Try traveling outside of the country then it gets even worse reaching a point where I just not use email because it is too much of a hassle.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
