WinForms Graphic Controls Question | Tech Off

sysrpl

Hi, I mostly do Delphi development but would like to start my next small work project in Visual Studio using C# and Winforms.

Right away I see that there is something so easy to do in Delphi and potentially difficult to do in WinForms. I am hoping maybe someone could explain to me how this UI design task could be accomplished easily with WinForms.

Here is my design goal:

I would like to design screens with graphical elements (controls positioned at design time) which overlap each other. These graphical elements do not accept user input, but usually convey some text, image, background, shape, or other drawn item. The key though is this: these items are not rectangles, they are words or shapes and colors that may overlap one anther.

Here is a screenshot from my Delphi prototype which uses GraphicControl classes (standard in Delphi) to accomplish my goal:

Above we have an image control, two text label control, and a infobox control (rounded edged, interior gradient fill). Notice that the infobox is in the back, the text on top of it, and the image (globe with people) is to the left.

Now I can easily create these layouts in the form design using Delphi, but with Winforms there is a problem, all controls are windows and thus rectangular. They will clip the drawing of the controls behind them and not give me the compisited per pixel transparency I am going for. See a closer look of of the screen above an notice the controls are blended together:

Notice the variable per pixel level alpha blending. So my question is, how can I create this same layout in the Winforms visual designer where controls have variable levels of alpha blending per pixel and are all layered together on on top of another?

I can think of one solution, which is to have a control that requests controls underneath it to paint themselves in it (typically by sending WM_PAINT with your DC and the origin offset).

Is this already handled by the Winforms framework?

Is there a simple method I can call to compisite controls together?

Have other people tackled this problem and solved it in a form that can be downloaded?

AndyC

Short Answer: Use WPF

Longer answer: Winforms doesn't support Windowless controls, so you're somewhat stuck with the limitations of windowed controls, including the rather rectangular nature. Generally for that sort of this you'd use a custom drawn control. Deplhi, which does support windowed and windowless controls has something of an edge here, but both pale into comparision with WPF which is vastly superior when creating rich graphical designs like the one you're demonstrating.

spivonious

In reply to AndyC

#Oct 21st @ 12:54 PM

I instantly thought of WPF when I read the first post. If you're stuck with Windows Forms, then you could try faking it using transparent backgrounds, but I think it will be more trouble than it's worth.

Dexter

You can try this sample: http://windowsclient.net/articles/shapedesigner.aspx

It's rather old but as far as I can see it still works, even in VS2010 beta 2 Smiley

sysrpl

In reply to AndyC

#Oct 21st @ 12:54 PM

In addition to weeks of my personal time this past summer and fall of last year, I've spent the last four work weeks re-evaluating WPF for line of business development. My conclusion is that WPF is not suitable for line of business development as compared to other technologies.

Prior to starting the evaluation I had specced and designed the application below:

http://imagebot.org/snapshops/new-work-app-final.jpg

Total time from planning, implementation, and testing to deployment was two weeks. I am looking for solutions which stongly favor main windows and dialogs that are chiefly data entry and selection screens, with static (non animated) images, icons, glyphs, background and text adornments.

AndyC

In reply to sysrpl

#Oct 21st @ 2:29 PM

I'd disagree with that, I actually think WPF is an excellent fit for LOB apps, including those that are mostly data-entry heavy forms. I think that, now Microsoft has shown a very firm commitment by utilising WPF in Visual Studio, you'll start to see a lot more apps moving down the WPF route and gaining significant benefits from doing so.

But given that you've ruled it out, why not just use Delphi? You clearly know it well enough to get the results you want in a reasonable time frame and there is little practical benefit it moving over to using C# if you're going to be hindered by the rather limited design of WinForms (which, let's face it, was always an intermediary technology until WPF was ready). It seems unwise to change technology for changes sake alone.

sysrpl

In reply to AndyC

#Oct 21st @ 3:33 PM

The job market has ruled out Delphi, both for job seekers and employers.

Resaon: Overwhelming demand for web applications web development and the death of desktop application development. What market was is left have been gobbled up by the increase in demand for .NET and true cross platform application development (Java or C/C++).

That's not to say Delphi is the cat's meow. It's not. Sure they've have added generics, attributes, increased reflection, inlining, full SMID instruction sets support, unicode. But it still has a stability issue. Your registered design time objects and any third party design time objects run inside the IDE and since it's native code, anything and everything can crash and bug out the IDE with the simplest of mistakes. Also, objects and visual elements cannot easily be packed into dlls for re-use unless you bring COM into the picture (which brings its own problems). But some straight forward, do anything you want in a UI using the Windows API, any C style APIs (OpenGL/fmod), COM and automation, and your/anyone's whole class/component/control library ... it's pretty damn good ... minus any future prospects for a job.

spivonious

In reply to sysrpl

#Oct 21st @ 2:29 PM

I think WPF is great for LOB apps too. I've created a couple small ones now and aside from the lack of an easy-to-use designer in VS2008, I haven't run into any major problems. The only things I've run into concern binding to Datasets, which MS obviously does not want you to do in WPF.

To get just the interface you posted in the picture (no functionality) would take less than a day now that I've coded up a few. And if you later want to change the color scheme, or which images are used, or how the various data items are displayed, it's as simple as changing which resource library the window points to.

sysrpl

In reply to spivonious

#Oct 22nd @ 6:56 AM

Thanks for the response.

WPF can be used, to be sure, but I was only giving my opinion, and I do welcome the opinions of others. After all, that's a primary purpose of this forum. However, I prefer to believe I posses an eclectic programming background (of course my opinion is biased in this regard), and that I've given WPF development a fair shake. Maybe you are right, and for whatever reason my ability to pick up and learn new technologies has suddenly diminished.

AndyC

In reply to sysrpl

#Oct 22nd @ 7:06 AM

I think WPF just has one of those epic "AHA!" moments, when it suddenly all starts making sense. Before that, it all seems a bit of an uphill struggle with no clear advantage. Pretty much like transitioning to OO after years of purely procedural programming.

I still think it's worth the effort though, particularly if your main aim is to widen your skill set to accomodate a better portfolio of tools. WPF skills are easily transferable to Silverlight for web development and that's something you're never going to get from learning WinForms.

YMMV, naturally. Smiley

spivonious

In reply to AndyC

#Oct 22nd @ 7:58 AM

Definitely has the "a-ha" moment. My first app was a total struggle and took me probably twice as long as the Windows Forms equivalent would have (and was far from an advanced app).

My second app, I realized how powerful data templates and commands were. WPF became fun and easy.

sysrpl

A quick followup. My goal can be accomplished (somewhat) in WinForms by parenting the overlapping controls together and setting the backcolor of the child to transparent.

It's not a totally ideal solution because the following restrictions apply: Child must be entirely within the parent or it is clipped. Siblings which overlap may cause graphical anomalies.

W3bbo
The Master of Baiters

In reply to sysrpl

#Oct 22nd @ 10:56 AM

I'd solve this problem by creating a custom "Banner" control that paints all of this itself. It would have various design-time properties that set the visual appearance (such as the text and images used) on a per-use basis. I don't think it'd take more than 10 minutes to write, maybe 5 minutes if I were more in-shape when it comes to WinForms contorls. Not as fast as Delphi, but less than the amount of time you've spent posting here.

sysrpl

In reply to W3bbo

#Oct 22nd @ 4:07 PM

W3bbo,

I tend to look for solutions which are flexible. Of course I could write a custom painting control. That's quite easy ... for a single design with a few variations. But what if I want a completely different layout or an unanticipated altered layout? With the "graphic" control design approach, changing designs involves moving things around with the mouse. Your plan would break easily as soon as you add one item you hadn't planned to the layout; for example, adding a link label inside the banner.

Rather than stumbling forward, I hope other developers seek and research quick, flexible solutions.

Frank Hileman
VG.net

http://www.vgdotnet.com

I believe this is close to your requirements.

Regards,

Frank

staceyw
Before C# there was darkness...

In reply to sysrpl

#Oct 22nd @ 5:40 PM

The issue you describe is basically where WinForms runs out of gas and WPF just starts. With winforms, you are kinda just stuck with what you have. No new research, no new dev tools, falling community, etc. If you looking for the good place to apply your time, I have to believe that is WPF for many reasons. Stuff like above (and much more involved) is just really simple with WPF. You just don't hit any brick walls. Granted, until 2010 RTMs, we have not had a real dev experience for WPF (i.e. no designer in VS has been a show stopper for many for starters) It should be much easier from what I have seen when we get vs2010. That said, you might not want to count out silverlight for some business apps either. SL has a lot to love for both the web and client dev.