Thanks, UpdateAllViews() will probably do the job. I did not realize that UpdateAllViews() has two user type parameters that I can use to pass my control data. Also, someone reminded me that the CFormView Object and the actual Window are two different things. So a "Direct" call (as I was calling it) goes to the object which will eventually pass messages to the attached window anyway. I knew that :zzz:, but was getting lost in the Doc/View world :confused: . Thanks for your time to respond !!!!! :) John

I have multiple CFormView windows in a MFC Doc/View application that uses a Multiple View CSplitterWnd based class to switch out views in two of the panes. To control the app, I need to pass messages between views. I have a central control class embedded in the app's CDocument derived class that controls all the views (and maintains access to pointers to the CFormView window object via the Splitter based class). Anyway, to the question - Should I: 1) Pass messages to the CFormView class DIRECTLY via a "virtual int SendViewMessage(...)" method since I have direct access to the CFormView based Objects; or 2) Should I post the messages via normal Windows Message (RegisterWindowMessage) to the CFormView and let the CFormView derived classes hanlde via Message Map. I'm not sure of the consequences of the DIRECT approach as far as the MFC Doc/View framework is concerned. I see CDocument and CView calling methods directly in MFC rather than passing messages. Is there a rule on this somewhere ???? Or, since all Doc/View framework in the same thread, does this matter at all ???? Any info would be appreciated !!!!!! Thanks, John

I can exit VC++, go right back in, and all the classes will be moved back under the main project folder in ClassView. It doesn't happen every time, but every few days or so. I'm not physically deleting the .opt file or anything. I happens on my Notebook as well as my normal desktop. Thanks for the input.

Visual C++ 6.0 Enterprise Edition, Service Pack 5. I have created SubFolders under my main Project Folder in the ClassView pane. Randomly (from what I can tell), ALL the Classes that I have moved under those SubFolders will move back to the main Project folder whenever I open the project. This is a major pain as I have to keep moving the classes back to the SubFolders in order to keep my project folder from getting to full to use efficiently. Am I misunderstanding something, or is this a bug ??? The SubFolders I created in the FileView Tab work fine. The files always stay in them. Anyone have any suggestions ????????? Thanks, John

The updates sound good. I'll be looking forward to them. As I implied in last post, I am a Dundas supporter and will buy the products again if needed for a new customer. Due to the time saved with Ultimate ToolBox classes, that project was on time with additional features. Customer very happy. The NT Service Classes and Threading Engine Class were life savers as I was not experienced in coding for either. Best of Luck in your new position and thanks for the feedback.:-D

BS in Computer Science. Started in Pre-Med Majoring in Chemical Engineering. The Fortran course for Engineering got me interested, but the Assembler course got me hooked. I loved the way those '1's and '0's worked. And I'm thankful everyday that I found my true calling. But, when I hire Programmers now, I don't put a lot of emphasis on the Degree. All 3 of the BEST PROGRAMMERS I've ever worked with did not have CS Degrees. It's the experience that counts. I STRONGLY believe in Testing for a position. I've tested newly graduated CS Majors who didn't have a clue about programming or life for that matter. I hate being a CodeProject LURKER because this site has been truely helpful to me, but I swear I am working on documenting and making examples for a couple of my classes and as soon as I get the time ..........

I have been VERY IMPRESSED with the Dundas classes I've used. The one time I contacted technical support early this year, someone called back the same day and he was very helpful. Maybe I received better than normal response because I registered under my Customers highly recognizable name (since they paid for it. But, I did notice the lack of new classes and decrease in useful info on their Web Site so we did not renew the Support Contract. A major problem in my project was the restrictions the "CORPORATE DESKTOP POLICE" put on the software, such as no Registry Updates, major DLL limitations, and so on. The use of Dundas Classes compiled in with our MFC Code rather than OCXs (or whatever M$ is calling Active-X Components this week) proved to be a life saver and saved MUCH time. Hopefully Dundas will get the Support Issues worked out, because I do like the quality of the products we used (Ultimate ToolKit and Grid).:cool: