From: Joseph M. Newcomer on
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
> ****
> 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
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

"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
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