Hi guys, I've got an MFC program that I've been developing for, well, since Windows 2000. We heavily leverage threads in this app - multiple background worker threads at a low priority, a rendering thread at a higher (but still below-normal) priority, then the main threads at a regular priority for the app to remain responsive to the user interaction with the GUI. It's worked great for W2K, WinXP, Vista, 7, and even 8 along with various flavour of each (though I didn't test much in Win 8). Now, with Win10, the GUI and in fact the entire operating system seems to be lethargic when the low priority threads are working - appearing to defeat the purpose of setting thread priorities. My threading library code hasn't changed, only the OS. And if I take the current build and run it on Win7, it behaves as expected. I've done a cursory review and can't find what's changed in the API to correct this. Did Microsoft change/break basic thread priorities in Windows 10, or am I missing something else? Thanks, --Rob

Found it! There is an intermediate class which inherited from CTreeCtrl. It was originally set up to support a CView, and forwarded the LButtonDown event to its parent. Well, now that the parent is a dockable pane, the behaviour changed a lot! Removing that handler got lots of stuff working!

Hi All, many thanks up-front to anyone who can help here. I have a client that wants me to migrate a CTreeView-derived class to one which works like a docking pane. The class is so large now that it's not feasible to rewrite everything. So...I still have the underlying CTreeCtrl-derived class (more/less untouched), which is a child of a class derived from CDockablePane (migrated from the CView class). I've also derived from CMultiPaneFrameWnd (used when the pane is floating) to try to trap events. I've got it working about 80%. I need help/direction with the other 20%. I've got the CDockablePane derived class working with bulk of the MESSAGE_MAP events (menu handlers, ON_UPDATE_COMMAND_UI, etc.) working correctly. The events associated with the mouse are giving me grief. I see 3 standard modes for the dockable pane: floating, docked, and tabbed. And they all behave differently w/r to mouse events - and depending on the docking mode. For example: * If the docking mode is DT_SMART *and* the pane is NOT floating, then drag&drop and double-clicking work correctly. * If the docking mode isn't DT_SMART, then drag&drop usually tries to drag the complete docking pane instead of working correctly (regardless of floating, docked, tabbed). * When the pane is floating, I can't trap WM_LBUTTONDBLCLK (unless you click on the lines and little [+] boxes...) or the respective notify or reflect messages - even Spy++ doesn't record them. I just don't see any left button double-click events - at all! Google searches show that I'm not the only one with these types of issues. I've read and tried pretty well every suggestion...and I still have these issues. I'm now concerned about bugs or assumptions in the framework after reading this: http://connect.microsoft.com/VisualStudio/feedback/details/641096/cdockablepane-calls-releasecapture[^] This link: http://www.johnbyrd.org/blog/index.php?itemid=405[^] helped a lot but didn't solve all issues either. I can also replicate these issues (unable to trap double-clicking when floating) in the VisualStudioDemo feature pack demo. Any sug

Mark Salsbery wrote:

I certainly wouldn't do that. C++/CLI is meant to be a bridge from native C++ to the managed .NET world. It should be used as that. Use the #pragma managed/#pragma unmanaged macros to control what code gets compiled managed and what stays native. Then you can keep your optimized or performance critical code compiled native. This can be done at the function level!

Hi Mark, I took your advice and created a new configuration in the project. Here, everything possible is native C++, and we're only using C++/CLI to provide the interface to one (previously COM) DLL. It was the easiest to use because it was the simplest. Plus it's used through-out the project quite a bit. Calculations are simple and quick. Another way to state this is we did nothing but change the interface technology from COM to .Net/managed on 1 DLL. We observed a performance impact of about 35% by just doing this change! :wtf: So we then put that entire DLL into CLR and the performance did improve - impact was around 23%. So in this instance the cost of switching from native->managed->native out-weighed the cost of executing the DLL code all as managed. But it's still a big hit from native C++. These #'s were surprising, to say the least...but are consistent with some tests we did about a year ago. One advantage of doing this exercise, though, was finidng some compiler options that needed to be changed, which improved the baseline performance (strictly C++). The above performance impact %-ages do not consider those gains, though. :omg: I'm not posting this to beat a dead horse, but am opening up this discussion to look for things we may have missed during our testing.:confused: --Rob

led mike wrote:

However COM is only necessary to support use of components developed in a different language. This is a heavy restriction and not a requirement for every project.

Yeah, unfortunately, defining the language of choice for projects outside my control, but using the object interfaces that I define, isn't an option - which mean COM or now .Net. Thanks, --Rob

Hi led mike, I believe that my comment needs more clarification. The motivations (maintainable, readable) are 2-fold and can be better defined as: 1.) I (personally) have never found that the IDL/ATL approach to defining/implementing COM object interfaces is particularly "clean". Nor has the ability to inherit from a COM object been "nice". I should have been more clear that the motivation is to use .Net technology instead of COM technology as a motivation to make it easier to deal with object interfaces intended for re-use outside this project. 2.) I'm (personally) probably one of the few that still enjoy some aspects of MFC for UI programming. But even I have noticed that it's more cost-effective to use more modern languages/features (such as C#) than MFC. And that means entering the managed land, at least in part. With respect to generic C/C++, these are still my personal language of preference for general day-to-day programming. I agree with you in that the choice of language doesn't necesssarily make code more/less easier to read. However, that language's technologies that we are (forced to?) use (e.g. ATL, MFC) do impact that legibility. As an aside, I'm doing more management and less programming, and our new staff is being trained (by local universities) to work in managed languages, with little or no exposure to C++. This is a reality that I'm not happy with but have to live with. This may be a problem in the future. --Rob

Mark Salsbery wrote:

Lastly, don't believe people that say managed code is slower

Actually...this is exactly what we're finding. Real world problem: - MFC application, 1 EXE and 5 DLL's. The DLL's do all the computations and are highly optimized C++ code which have been validated for correctness and operation many times in the past decade. And we have spent many late nights finding performance gains - the code is good. The front-end is GUI. We have MFC, STL, ATL technologies incorporated, plus a lot of hand-written code - because STL was too slow. The DLL's implement linear algebra, various geometry calculations, and 1st-order PDE's. There are also simple array/table look-ups. The project is 300,000+ lines code. - we also use ZLIB, GDAL/OGR, CGAL but they aren't used in these tests Test results: - baseline is current release build, test case taks 190seconds. - simply turn on the /clr switch on as many files as possible (following the bouncing ball, trying to do it right) and performance drops to 345 seconds (not all could run managed because of MFC) - retest native release build, it stays the same - concerned we are doing too many native/managed swaps to translate 1 DLL to entirely a C++/CLI classlib, performance drops to 355 seconds. Confused so try it again, 361 seconds - try NGEN on the classlib, performance becomes 349 seconds - try NGEN on the entire project, performance becomes 476 seconds! - back out of changes, start over with the native release build, back around 188 seconds - incorporate the classlib and do MINIMUM required to get things to link back together (to use native as much as possible) and performance is around 244 seconds All other test cases yield similar results. We WANT to move to .Net (to clean up the code, make it easier to maintain and read, etc.), but we need a migratory path where we don't have to rewrite the entire front end out of MFC right away. But these performance #'s just suck. We can't ask the client to live with such poor performance during migration in hopes it will improve when it's all done and running strictly in managed. We have experience with C# in another project but are new in the C++/CLI world. I'd happily discuss this online or offline but 'til then I can't agree with your comment at all Mark! --Rob