When I'm stumped, I look here first. When I'm just bored and looking to learn something, I browse articles of interest here. 'Nuf said. FWIW, I've made a LOT of posts over at the MSDN forums, and to be frank, it's a rare thing that I get a reply that actually helps me solve a problem. D. T. Doutel

I'll look into that; thank you! D.T. Doutel

Hey folks, Anyone know what I need to do to get the tab key to move from field to field in a CPropertyPageImpl-based property sheet page? it works fine in design view in VS, but sounds a bell and stays put when executing. All the necessary controls have the WS_TABSTOP set, but the focus doesn't move... Thanks! D. T. Doutel

I usually work in C#, but of late have had to resort to C++ for a BHO project. Regardless of what keyboard configuration I select, or what type of indenting I have set for C++ source files, the Tab key is dead in the VS2010 C++ code editor. I can switch over to another tab which has a C# source loaded, and the Tab key works fine, as it does outside VS in every other app I run. Reset to Defaults makes no difference. Anyone else run into this, and if so, have you figured it out? Best, D. T. Doutel

Nevermind; until IE knows how to deal with the possibility of multiple versions of the CLR in-process, if indeed that's even possible, C++/CLI won't make any difference.

Just getting back to C++ after a long hiatus in C#, and am designing a product that's going to need an ATL IE BHO. It occurs to me that if the managed/unmanaged modules were partitioned properly, there might be some significant advantages in being able to use the CLR. I chose to use C++ rather than C# for the BHO portion of the project because I understand that there are issues with potentially having more than one version of the runtime in-process with IE. Anyone here ever considered/tried this strategy for an ATL COM object that interops with the CLR? If so, what kind of issues have you run into? Thanks! D. T. Doutel

To whomever it was that recommended to me in this thread the book Pro WPF in C# 2008 by Matthew MacDonald, I owe you a debt of gratitude; many thanks! Edit: this gentleman turns out to be JHubSharp; dude, this Bud's for you! ;) Best regards, D. T. Doutel

Thank you! I'll look into that one! Best, Duane

I would have, had I known...

Actually, Andrew, I'm betting I don't get a response at all! MS actually talks a good game when it comes to saying they want input from the trenches, but from what I've seen, if your name is not known to them...well, you get my point. Yes; completely agree with you regarding the "we'll support it until we won't". Also agree with you regarding the reason for wanting MDI support in WPF; it's not that I like MDI (that would be a strange fetish, indeed), but when you need it, you need it, and anything else is gonna be awkward in a sense that it'll leave your users scratching their heads and wondering what the developer was thinking, at best. Appreciate all the replies, gentlemen! I have a feeling it more than I'll get from ScottGu, busy guy that he must be. Best, Duane Doutel

Computafreak wrote:

I agree about your point on MDI support. It's a nightmare trying to host a WPF Window in a Windows Forms Form; I can't even get it to be constrained by the bounds of the MDI client properly

That's odd; I've not had problems with that part of it...

dan neely wrote:

If you get a response, please post it here.

I'll gladly post any reply I get, but I won't be holding my breath...! :|

Pete, I don't want to be argumentative, but I'd hardly call those current; both were posted in '05... I'd just like to have good ol' child windows in a main frame, ala WPF. No tabs; I need to be able to constrain the children to free-floating columns in the frame, with perhaps a DockPanel + children in them, nothing fancy; I know Tony Gordon has done this. But unless I'm mistaken (a VERY distinct possibility), it's not a 'complete' implementation. Look, compared to you guys, I know very little about WPF. I had in mind a project as something worth doing/fun to do to help me get up to speed, and I'm finding after a good bit of looking at it that it won't suit the project, which kinda defeats the purpose. In fact, I think you may have been one of the ones who convinced me I should take another look at it in a thread I started here a few weeks ago. ;) Regards, Duane

modified on Wednesday, May 27, 2009 5:30 PM

Hi Scott, I’ve tried the MSDN support phone #’s, forums, etc, and the standard line I get from the support-types is that ‘we don’t have access to our developers’. What I have is a few comments to make regarding WPF that would just never reach the ears of anyone with the authority to make any difference unless I write you personally. Please forgive me for taking this liberty with you. First, my qualifications to make these remarks: I’ve been a developer for thirty years now, 28 of those under Microsoft platforms using Microsoft tools and API’s. I came up through assembly language to C to C++ to C#, and a bunch of other stuff as side trips. I’ve written everything from kernel-mode drivers to web applications. In short, I’ve more than earned my spurs, and the right to raise an issue with a Microsoft developer product or API. Now I’ll get right to the point. Is WPF clever, perhaps even revolutionary, a major jump forward in UI development? Yeah, I suppose so. But in order for a “new thing” to replace an “old thing”, it first needs to provide all the functionality of the “old thing”, and then some! What I’m talking about is MDI support, and I do not mean ElementHost or its’ WPF counterpart. Hybrids present a whole host of issues; no need to belabor them here, no doubt you’re more conversant in them than I am. I’ve found old discussions regarding the lack of MDI support in WPF from three years ago (discussion dropped, never updated), and I’ve found some ‘roll-your-own’ “solutions” on forums here and there that at best stop-gap measures. I’ve even found posts and articles over on CodeProject.com where folks have tried to FAKE an MDI using Tab controls! I give these folks enormous credit for making the best of a bad situation, but honestly, why should they have to? I really used to enjoy the bleeding edge, all-night voyages of discovery, but these days, I find I actually need to sleep now and then… I don’t want to fake or roll-my-own support for something that clearly belongs in WPF, regardless of the clear disdain Microsoft seems to be showing for MDI these days. Believe it or not, there remain some programming problems for which there is still no better solution! Add to the above that the WPF tools, be they Blend or VS are not a lot of help, and WPF documentation is, to my mind, pretty sparse. So what gives, Scott? Is MDI going to be implemented as a first-class citizen of WPF, or is it now ‘deprecated’? Bottom line for me, WPF is a long way from being capable of supplanting WinForms anytime soon; it’s a

I have; both Blend and VS 2008.

ROFL! You're right! I AM old...! <W_C_Fields_Mode> "Go 'way, kid, ya bother me...!" </W_C_Fields_Mode> Agree; that "disconnect" between the Framework and the XAML is all the more acute if you don't have a firm grip on the XAML, and I don't. I know MS touts this "feature" as cool, because you can 'hand off the XAML' to a designer while the programmer works on the code, but as I said in my opening rant, how many of us really have that luxury? I mean, come on! You're lucky to get stick figures outta me...! ;-P Best Regards, Duane Doutel

modified on Wednesday, May 13, 2009 5:41 PM

I hear ya! The .XAML is really nothing more in appearance than a DOM-like thing, and even in a moderately complex one, it's easy to get lost. I've never gotten to the point where the designer croaked, but I can just imagine the frustration... Best Regards, Duane Doutel

Thank you; I'll have a look at these! Best Regards, Duane Doutel

I agree about the tools; between VS 2008 and Blend 2.1, and not having a large amount of time to spend in a chunk to grok it all, it's just not gel-ing for me. Add to that that in spite of having invested in several books, being an MSDN Premium subscriber, and reading a bunch of the stuff at CodeProject, the markup is neither A)introduced well at all, nor B) covered comprehensively in a single place. To top it off, it would seem that one of the supposed strengths of WPF is in the graphics department, and the extent of my graphics experience is in writing Windows printer device drivers many years ago (dithers, diffusions, etc.); in short, I'm no graphics designer. Best regards, Duane Doutel

modified on Wednesday, May 13, 2009 5:34 PM

Thanks, Pete; I'll read that for sure. I'm for anything that actually DOES make my job easier; there's more than enough to worry about without having to fight the tools, too. D. T. Doutel