Prev: How to let a CFrameWnd based SDI application start in full screen?
Next: update CDialog region in a user defined message handler
From: Joseph M. Newcomer on 14 Jun 2010 11:46 As I pointed out, VS2005 erroneously maintains the "public" nature of control variables (although you *can* change it, most people don't know they *should*) and of handlers (you are not given a option to change their visibility, a fudnamental design error, given they are erroneously marked 'public'). I always hand-edit my .h files to lump the handlers together (in a 'protected' area), lump the variables together (in a 'protected' area, often in alphabetical order), and so on, instead of taking the horrible misorganization the new tools seem to think would be acceptable. joe On Mon, 14 Jun 2010 09:59:33 -0400, "RB" <NoMail(a)NoSpam> wrote: >Thanks Joe, another novice stupid move on my part. One >thing about me, I am not afraid to screw up in order to move >forward. > But in reference to the dangerous code that you so informatively >detailed, I have rectified it (with the help of Giovanni ) and it is >now working great and I have learned another facet of programming >that hopefully will stick with me enough not to do it again. In >retrospect I had a hunch previously that much of what you said was >the case from remembering long ago when I tried writing small simple >API apps that had child windows. > This has taught me that I am leaning too much on what is visually >available in the Class Wizard rather than having the foresight to >have looked in the docs for CDialog class I would have found >in the OnInitDialog class member text, clearly showing that it >was the function I was needing. Even though I have my VS2005 >now, I still do my experimentations in VC6 since I am so used to >it. But this is yet another reason to move on even in that facet. >If I don't see you on this group again, thanks ever so much for all >your help. RB > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: RB on 14 Jun 2010 17:39 > **** > CWnd is the MFC class > CWindow is the ATL class > CWindow is a stripped-down lightweight class for use in ActiveX controls > (primarily in ActiveVIrus controls, those controls whose purpose in life is to > be blocked by intelligently-configured browsers) > You would not use CWindow in an MFC app. > **** Thank you, I will note that. > You are clearly confused about "agendas" here. The "agenda" on > WM_INITDIALOG is to allow YOU to do what YOU want with the controls > in the dialog. As such, it is not issued until all the controls are created. The > CDialog::OnInitDialog virtual method reflects this functionality. Note that the > root CDiallog::OnInitDialog calls the virtual method DoDataExchange, and your > .................................. > So I'm not sure what "agenda" is going on here. It *specifically* exists to allow > you to implment "your agenda". > joe > **** Thanks again for the elaboration. I was attempting to describe my confused state on using the return of OnInitDialog for my return value. Apologize for ambiguity on my part in doing so. I do understand that I had the whole return idea wrong. RB
From: JCO on 14 Jun 2010 19:54 I think I'm missing something but I'm interested in this topic. If you have your version defined in a header file, then you can display it in the dialog, however, if you did a "property" on the exe file, has it really changed? If so, then I got lost somewhere in this thread. Also; I was under the impression that you can set something in VS that allowed the version to change each time you do a build. I don't remember how to do this but I always thought this was possible. Now it may only change the Build number and not anything else, however, this is a good feature. Is this still possible, if so .... how do you do it? Thanks "Giovanni Dicanio" <giovanniDOTdicanio(a)REMOVEMEgmail.com> wrote in message news:eg3hiCyCLHA.2012(a)TK2MSFTNGP02.phx.gbl... > On 13/06/2010 15:47, RB wrote: > >> void CFileHandlingApp::OnAppAbout() >> { >> CAboutDlg aboutDlg; >> CString s; >> s.Format( _T(" version %d.%d.%d.%d"), VERMAJ, VERMIN, VERFIX, >> BUILDNUMBER ); >> aboutDlg.m_CtrlStaticVer.SetWindowText(s); //gets a Debug Assertion >> Failed >> aboutDlg.DoModal(); > > You may want to add a method to your CAboutDlg class like > SetVersionString(LPCTSTR pszVersion) and a data member of type CString > (e.g. CString m_strVersion). > This new method should set the version string, storing it into the proper > data member. > > Then, CAboutDlg::OnInitDialog would get this string and .SetWindowText() > it in the proper static control. > > e.g.: > > class CAboutDlg > { > ... > public: > void SetVersionString(LPCTSTR pszVersion) > { > m_strVersion = pszVersion; > } > > ... > > private: > CString m_strVersion; > }; > > In CAboudDlg::OnInitDialog() do: > > m_CtrlStaticVer.SetWindowText(m_strVersion); > > > Giovanni
From: RB on 14 Jun 2010 22:09 "JCO" wrote >I think I'm missing something but I'm interested in this topic. > If you have your version defined in a header file, then you can display it > in the dialog, however, if you did a "property" on the exe file, has it > really changed? If so, then I got lost somewhere in this thread. Well I think I can show you that part since it does work on my App. See code at bottom. > Also; > I was under the impression that you can set something in VS that allowed the > version to change each time you do a build. I don't remember how to do this > but I always thought this was possible. Now it may only change the Build > number and not anything else, however, this is a good feature. Is this > still possible, if so .... how do you do it? I will let Giovanni respond to that since I am used to using an old version of VS that does not (that I am aware of ) do this. ----pasted pertinant code to version going to Exe (and any DLLs) on build I put the below into my AppVer.h file. This is the one source for version data. Include this file in each file that needs access to version data // Stringisation. // (Two steps needed). #define _STR(x) #x #define STR(x) _STR(x) // The following are used as defined quantities // in the versioninfo resource: #define VERMAJ 1 #define VERMIN 0 #define VERFIX 0 #define BUILDNUMBER 0 #define VERMAJSTR STR( VERMAJ ) #define VERMINSTR STR( VERMIN ) #define VERFIXSTR STR( VERFIX ) #define BUILDSTR STR( BUILDNUMBER ) #define VERSIONSTRING VERMAJSTR "." VERMINSTR "." VERFIXSTR "." BUILDSTR #define PRODUCTSTRING VERMAJSTR "." VERMINSTR "." VERFIXSTR "." BUILDSTR #define CORP_NAME "RBC" // used in file serialize data #define CPY_RIGHT_YR "Copyright (C) 2010" // used in CAbout dialog // along with VERSIONSTRING ----Now as to the Exe properties part, what I did was look in my AppWizard generated rc file, and cut out the CAbout dialog defined section, and then paste it into rc2 file, i.e. /////////in my rc2 file/////////////////////////////////// // Add manually edited resources here... #include "AppVer.h" // this is the one version source // From here down was cut out of Project rc file and then pasted here // and then edited to receive the defines from the AppVer.h file // See edits below #ifndef _MAC VS_VERSION_INFO VERSIONINFO //--in the original rc file section this used to be // FILEVERSION 1,0,0,1 --// FILEVERSION VERMAJ,VERMIN,VERFIX, BUILDNUMBER PRODUCTVERSION VERMAJ,VERMIN,VERFIX, BUILDNUMBER FILEFLAGSMASK 0x3fL #ifdef _DEBUG FILEFLAGS 0x1L #else FILEFLAGS 0x0L #endif FILEOS 0x4L FILETYPE 0x1L FILESUBTYPE 0x0L BEGIN BLOCK "StringFileInfo" BEGIN BLOCK "040904B0" BEGIN VALUE "CompanyName", CORP_NAME "\0" //*EDITED VALUE "FileDescription", "FileHandling MFC Application\0" VALUE "FileVersion", VERSIONSTRING "\0" //*EDITED VALUE "InternalName", "FileHandling\0" VALUE "LegalCopyright", CPY_RIGHT_YR "\0" //*EDITED VALUE "LegalTrademarks", "\0" VALUE "OriginalFilename", "FileHandling.EXE\0" VALUE "ProductName", "FileHandling Application\0" VALUE "ProductVersion", PRODUCTSTRING "\0" //*EDITED END END BLOCK "VarFileInfo" BEGIN VALUE "Translation", 0x409, 1200 END END #endif // !_MAC ---The above will show in the properties when you right click on exe. Note I had to leave a space between the DEFINE and the NULL i.e. VERSIONSTRING "\0" and not VERSIONSTRING"\0" or I got a " in the output. I choose to keep the "\0" separate from the #defines since I used some of them later for sting literal initalizers. Otherwise I guess you could include it in the define.
From: Giovanni Dicanio on 15 Jun 2010 05:15
On 15/06/2010 01:54, JCO wrote: > I was under the impression that you can set something in VS that allowed > the version to change each time you do a build. I don't remember how to > do this but I always thought this was possible. Now it may only change > the Build number and not anything else, however, this is a good feature. > Is this still possible, if so .... how do you do it? Are you thinking of something like this? http://www.codeproject.com/KB/dotnet/build_versioning.aspx Giovanni |