Why isn't there a designer for native api forms in Visual Studio? Similar to Delphi? If there exist some programs, tools etc, please advice.
What is the best approach to design complex windows in pure API?
A:
It's because of Microsoft. They've already moved towards dotNet and C#. Visual Studio 2005 has nice GUI editor for those. Why do you need to use the pure API ?
CsTamas
2009-07-17 10:06:36
[irony] Of course only Microsoft is allowed to implement such a thing, right?[/irony]
peterchen
2009-07-17 10:28:16
Coming from a Delphi background, I've always wondered how developers managed to make complex windows with pure API. Like back in the days.And in the end the project is gonna be cross-platform. But I have already settled for making it from scratch, while I learn VS and C++ at the same time :) If I only manage it before deadline.Already thought of making the complex window in .NET or Delphi, and put in a DLL. Easier/cheaper for maintanance as well.
Ricardo
2009-07-17 15:56:59
A:
There's ressource editor for dialogs, and then there is code. I've never really missed some visual design tool, though some better support from the controls themselves would be nice.
The core problem is the abstraction level: using just Win32 controls, designing a complex GUI needs some forethought, and the controls all have slightly different oddities, capabilities and features. They don't have a common interface that can be used to build a designer on top.
WinForms was designed from the ground up with designer support in mind, and it shows. The main design concern of Win32 controls was memory footprint of code and data.
Even MFC (which still shows many signs of memory scarcity) doesn't abstract these oddities away well enough to warrant a decent forms designer.
All environments that come with a decent forms editor (I remember Watcom ++ / Optima, ZINC, and quite some others I've forgotten the names of) also come with a decent forms library with a high abstraction level.
Then, there's the problem of modifications. What should be the designer's output? One could shoot for an XML data file, but that would add a dependency to some large libraries to your native app - doesn't make much sense. Or you create code, but C/C++ isn't well suited to that. Another binary format? You'd limit yourself to what the designer allows.
In the end, the designer would have to take care of each control separately, and still could not isolate you from knowing the controls and window mechanisms inside out. It was never undertaken when C++ was the first choice for large scale desktop development. Adding it now, when there are - arguably - better choices, would be a rather stupid move.
peterchen
2009-07-17 10:27:21
Thank you for your comment :)Agreed. Why it was never done, was more what I was wondering about.Why couldn't MS implement something similar to VCL in Delphi?
Ricardo
2009-07-17 16:05:37
As said, MFC as it was - and is - isn't suited anymore than pure Win32. Maybe they realized that with MFC and ATL they had invested enough into UI frameworks to not tackle a 3rd branch at the same level. Business-wise, probably a good decision to put the ressources into .NET instead. But that's just speculation.
peterchen
2009-07-17 21:02:26
A:
That's probably because there is no standard way of doing control layouts in WinAPI, you have to manage it by yourself. There is no base "Control" class in WinAPI - everything is a Window of some sort, so no way to support their differences with a common layout editor/designer.
You can however create your window layout in a dialog and make it resizable by yourself or using methods published on codeproject (this or this - both are MFC-related, but that's fairly easy to translate).
Or adapt ScreenLib to your desktop needs.
macbirdie
2009-07-17 10:29:27
Thanks! Interesting and helpful articles. This pointed me in the right direction :)
Ricardo
2009-07-17 16:09:58