I'm enjoying learning it, but I've come up against a roadblock in my current design. I have a feeling it's a question any seasoned .NET programmer could answer in 5 minutes, but no since in me spilling my guts if it's to an empty audience...

So, anyone out there have more than a passing familiarity with .NET and managed components?

 

I'm a .Net Technical Architect, drop me a PM and I'm sure I can help you out

 

Jeff,

I'll post my problem in the open so others can see it, but feel free to send any replies to dhintz_SPAM_@bsttv.com (remove the _SPAM_). The initial explanation is a bit long-winded.

I'm converting an unmanaged app (originally written using VS 6) over to one that is managed (currently using VS 2008). The app uses a small dialog stored in a resource file, which is copied to a 2x10 array to make up the main interface. The dialog consists of a few text boxes, checkboxes, spin controls, progress bars, etc. It's the progress bar that's giving me so much trouble.

Part of the "upgrade" process is improving the GUI's functionality. The progress bars are used as signal strength indicators, so you see 40 little blue bars jumping around... not very easy to follow with the eye. Based upon article KB816195 (an unmanaged progress bar replacement written for VS 2005), I created a managed version of the component that changes color (among other things) based upon its value. More eye pop, right? This was all packaged up into a DLL and tested on a blank project form... works great, looks great.

I ran into my first SNAFU when I tried to add it to the Toolbox while editing the dialog... it was grayed out. Long story short there, after a few Microsoft forum question and answer sessions it appears you cannot use managed components on dialogs, only forms.

A suggested kludge was a How-To article titled "Create the User Control and Host in a Dialog Box", which essentially places a managed component inside of a MFC dialog on top of an MFC application (compiled with /clr), with a static text control acting as a placeholder for the component.

Soooooo... here are my questions:
1) Is there an easier way for dialogs, similar to the drag-and-drop design method used for forms?
2) If not, must I design my main application using MFC as suggested in the above How-To, or can I go with .NET all the way? I'm wondering if it's the MFC-style dialog that allows for the data exchange of a managed component to work, something that simple .NET-style dialogs don't offer.
3) If I can compile the main app with .NET-style dialogs (as I am now) and still use my new managed components, how do I go about it?

Thanks,
Dan

 

Hey Dan,

I only have a second (about to run to lunch with some of my co-workers)....

I'll take a look at your problem in some more detail a bit later, but I haven't worked with a Forms app in forever so I'm a bit rusty (I primarily work on enterprise web-based applications), but I may be able to lend a hand

Jeff

 

if only i stayed at a holiday inn express last night.....

 

 

But I did save 15% on my insurance by switching to Geico.

 

Hey Dan,

Finally got a few minutes. As I mentioned before it's been a really long time since I've built a windows application (I assumed your question was more language or framework specific).

With that said, have you considered building your dialog as a regular old form but instead making it a) modal and b) have the same "look and feel" as the dialog you're trying to add controls to?

Let me see if I can dig anything up on this that might be of use to you! Again I'm not a windows forms app coder so I can only be of limited use on this one