My Review of MFC Beta

Well....after reviewing the MFC beta here is my opinion, for any one
who cares.

As every one knows, First of all this is not a MS native library. Some
third party library being decorated in MFC dress. Given that there
should ideally be a lot of color and convenience for the customers -
but my expectations were proved to be too optimistic. Here is why.

 1. Most of this MFC beta covers what most people consider as just
"skin deep", if you know what I mean. If you remove the "theme" part -
the new enterprise controls introduced to MFC are the Dockers and the
property grid.

2. The "theme"/coloring/window style/visualization/ribbon, you name
it, is just a "painting effect" and not the original ribbon code of MS
Office. Given that, the prime question posed by many is why MS should
release a library that "mimics" the Office theme when they could port
the Office theme code to MFC and release it. Well I do not want to
talk about it - may be some licensing issues.

3. Since the theme portion is a "mimic" effect, can the user define
and create new themes with this so called Visualization Manager of MFC
beta?  Nope !! You only get few "hard coded" themes - and like a big
teddy bear you have to select only among those four or five themes.
You cannot extend or override the predefined themes - at least I could
not find any provision for that in the code. And who really cares
about that weird Ribbon menus? What extra enterprise functionality
your customers would gain if you modify your tool bar to look like a
huge horizontal bar with extra large icons?

4. Coming to Source code, well...its a poor job too. Take a look at
any of the MFC beta new controls' source code and you would know what
I am talking about. The first prominent thing you can find is the
abundant misuse of "friend class" feature, followed by the next misuse
of "public data members".  Not to mention about the global data
structures without a namespace or accessor functions.

5. As for the controls themselves, are they efficient? Well...I am not
sure - at least I was not impressed. May be I was wrong with this one
- but many times I came across unnecessary flickering with controls
when resized or re-layed out. May be there are functions inside that
we can override to optimize this - but I could not easily find them.

6. And are the controls extensible? Well, take a look at the property
gird - it has hard coded property editors for spin control, combo box.
Beyond that you cannot have your own in-place editors, such as check
boxes (for true/false) or slider control (for integers). Nor could I
find much support for extending the stock editors !!

7. The BCGSoft website has offered samples demonstrating the use of
few Grid controls such as report grid and multi-column tree view
controls etc... But I could not find any Grid control at all inside
the MFC beta !! Wondering if MFC beta is kind of "trial" version of
BCGSoft control libray, where if you like the MFC then you should go
and buy the full BCG Soft Control bar library.

All in all - the only real useful feature I can find in this version
(for enterprise level software) is - the docking ability for windows.
Beyond that the controls do not stand upto the level of MFC, nor the
code does.

Now having cribbed enough about this - lets put few points that could
make the VC++ robust. Lets think about What we really want from VC++.

 The answer is simple: Lets have VC++ give all that the .Net is
providing to its developers. In otherwords,

 1. We need the ability to generate, compile and build VC++/Win32/COM
dlls on the fly. We have been using VC++ compiler for so many years,
they never had the thought of making it re-usable API or component,
where as the .Net had this feature built in right from the startup.
   Why dont we have our cl.exe (and all other apps that are
responsible for compiling and generating the dlls) exposed as API?
Note that the major power .net has is because of its meta data and its
usage in reflection. We DO have metadata for native dlls too - in the
form of type-libraries for COM. But we are limited in our reflection
ability - we cannot dynamically create a COM dll in memory and load
its types from another App. We NEED this ability.
   This could bring a huge leap for VC++ developers. After all, today
they talk about ASP.Net with code behind .net assemblies. If those
bloated .net assemblies can bring ASP.net so much power, then imagine
how much  power c++ native dlls could bring to the web applications.

2. We need all the latest controls the .Net is offering to its
developers: Right from the layout panels to the Property Gird UI
editors, Form design surfaces, Tray Icon notifiers, Visual Studio
debug visualizers...all accessible as WTL controls or MFC/Win32
controls. (Note that once we have the ability to generate C++ dlls on
the fly this should become possible and easy.)
    We need all the sleek looking Grid controls, report controls, mult-
column tree controls, property grid controls, HTML surface controls
(to bring the effect of styles/themes to our native applications, just
like those website styles/themes) ...

3. More importantly - stop pushing managed C++. This alone could be a
very big boon for all of us. Give us native XML parsers and do not
deprecate the SOAP tool kit.

 These should be enough for now.


PS: These are my personal opinions. You may or may not agree with them.
0
1/17/2008 5:47:44 PM
vc.mfc 33608 articles. 0 followers. Follow

8 Replies
369 Views

Similar Articles

[PageSpeed] 34

Nice write up and thanks for your thoughts.

I think the new controls from BCGSoft are only the ribbon and skinning 
controls.  The skinning controls include the toolbar, menu, etc.  The 
treelist (report) grid is not included (I asked) and some other BCGSoft 
controls like the date, editor, etc. are not included.

I think this will improve the average user's out of the box experience and 
I'm glad Microsoft was willing to get the controls they did.  Many people 
have asked for this sort of functionality over the years.  Perhaps they will 
extend it as time goes on and requests for more tools comes in from users.

Tom

<NightHawkMailBox@googlemail.com> wrote in message 
news:2f9125f7-04b8-42cc-95c6-17a20101d65c@i72g2000hsd.googlegroups.com...
> Well....after reviewing the MFC beta here is my opinion, for any one
> who cares.
>
> As every one knows, First of all this is not a MS native library. Some
> third party library being decorated in MFC dress. Given that there
> should ideally be a lot of color and convenience for the customers -
> but my expectations were proved to be too optimistic. Here is why.
>
> 1. Most of this MFC beta covers what most people consider as just
> "skin deep", if you know what I mean. If you remove the "theme" part -
> the new enterprise controls introduced to MFC are the Dockers and the
> property grid.
>
> 2. The "theme"/coloring/window style/visualization/ribbon, you name
> it, is just a "painting effect" and not the original ribbon code of MS
> Office. Given that, the prime question posed by many is why MS should
> release a library that "mimics" the Office theme when they could port
> the Office theme code to MFC and release it. Well I do not want to
> talk about it - may be some licensing issues.
>
> 3. Since the theme portion is a "mimic" effect, can the user define
> and create new themes with this so called Visualization Manager of MFC
> beta?  Nope !! You only get few "hard coded" themes - and like a big
> teddy bear you have to select only among those four or five themes.
> You cannot extend or override the predefined themes - at least I could
> not find any provision for that in the code. And who really cares
> about that weird Ribbon menus? What extra enterprise functionality
> your customers would gain if you modify your tool bar to look like a
> huge horizontal bar with extra large icons?
>
> 4. Coming to Source code, well...its a poor job too. Take a look at
> any of the MFC beta new controls' source code and you would know what
> I am talking about. The first prominent thing you can find is the
> abundant misuse of "friend class" feature, followed by the next misuse
> of "public data members".  Not to mention about the global data
> structures without a namespace or accessor functions.
>
> 5. As for the controls themselves, are they efficient? Well...I am not
> sure - at least I was not impressed. May be I was wrong with this one
> - but many times I came across unnecessary flickering with controls
> when resized or re-layed out. May be there are functions inside that
> we can override to optimize this - but I could not easily find them.
>
> 6. And are the controls extensible? Well, take a look at the property
> gird - it has hard coded property editors for spin control, combo box.
> Beyond that you cannot have your own in-place editors, such as check
> boxes (for true/false) or slider control (for integers). Nor could I
> find much support for extending the stock editors !!
>
> 7. The BCGSoft website has offered samples demonstrating the use of
> few Grid controls such as report grid and multi-column tree view
> controls etc... But I could not find any Grid control at all inside
> the MFC beta !! Wondering if MFC beta is kind of "trial" version of
> BCGSoft control libray, where if you like the MFC then you should go
> and buy the full BCG Soft Control bar library.
>
> All in all - the only real useful feature I can find in this version
> (for enterprise level software) is - the docking ability for windows.
> Beyond that the controls do not stand upto the level of MFC, nor the
> code does.
>
> Now having cribbed enough about this - lets put few points that could
> make the VC++ robust. Lets think about What we really want from VC++.
>
> The answer is simple: Lets have VC++ give all that the .Net is
> providing to its developers. In otherwords,
>
> 1. We need the ability to generate, compile and build VC++/Win32/COM
> dlls on the fly. We have been using VC++ compiler for so many years,
> they never had the thought of making it re-usable API or component,
> where as the .Net had this feature built in right from the startup.
>   Why dont we have our cl.exe (and all other apps that are
> responsible for compiling and generating the dlls) exposed as API?
> Note that the major power .net has is because of its meta data and its
> usage in reflection. We DO have metadata for native dlls too - in the
> form of type-libraries for COM. But we are limited in our reflection
> ability - we cannot dynamically create a COM dll in memory and load
> its types from another App. We NEED this ability.
>   This could bring a huge leap for VC++ developers. After all, today
> they talk about ASP.Net with code behind .net assemblies. If those
> bloated .net assemblies can bring ASP.net so much power, then imagine
> how much  power c++ native dlls could bring to the web applications.
>
> 2. We need all the latest controls the .Net is offering to its
> developers: Right from the layout panels to the Property Gird UI
> editors, Form design surfaces, Tray Icon notifiers, Visual Studio
> debug visualizers...all accessible as WTL controls or MFC/Win32
> controls. (Note that once we have the ability to generate C++ dlls on
> the fly this should become possible and easy.)
>    We need all the sleek looking Grid controls, report controls, mult-
> column tree controls, property grid controls, HTML surface controls
> (to bring the effect of styles/themes to our native applications, just
> like those website styles/themes) ...
>
> 3. More importantly - stop pushing managed C++. This alone could be a
> very big boon for all of us. Give us native XML parsers and do not
> deprecate the SOAP tool kit.
>
> These should be enough for now.
>
>
> PS: These are my personal opinions. You may or may not agree with them. 

0
tom.nospam (3240)
1/17/2008 6:19:52 PM
<NightHawkMailBox@googlemail.com> wrote in message 
news:2f9125f7-04b8-42cc-95c6-17a20101d65c@i72g2000hsd.googlegroups.com...
> Well....after reviewing the MFC beta here is my opinion, for any one
> who cares.
>
> As every one knows, First of all this is not a MS native library. Some
> third party library being decorated in MFC dress. Given that there
> should ideally be a lot of color and convenience for the customers -
> but my expectations were proved to be too optimistic. Here is why.
>
> 1. Most of this MFC beta covers what most people consider as just
> "skin deep", if you know what I mean. If you remove the "theme" part -
> the new enterprise controls introduced to MFC are the Dockers and the
> property grid.
>

Do you not find this extra benefit attractive?  Several months ago, I used a 
property grid from CodeProject but it would have been more convenient if 
this had been available to me, as it will be now.



> 2. The "theme"/coloring/window style/visualization/ribbon, you name
> it, is just a "painting effect" and not the original ribbon code of MS
> Office. Given that, the prime question posed by many is why MS should
> release a library that "mimics" the Office theme when they could port
> the Office theme code to MFC and release it. Well I do not want to
> talk about it - may be some licensing issues.
>

Well, to be blunt, so what?  What do we care whether it is the same code 
that is running in Office 2007 or not?  Actually, I'm glad it's not the 
same, as the first one is bound to be hacked up and not well factored; first 
attempts often are.  By completely rewriting the API to achieve the same 
goal, I'm sure it is much cleaner than the original.



> 3. Since the theme portion is a "mimic" effect, can the user define
> and create new themes with this so called Visualization Manager of MFC
> beta?  Nope !! You only get few "hard coded" themes - and like a big
> teddy bear you have to select only among those four or five themes.
> You cannot extend or override the predefined themes - at least I could
> not find any provision for that in the code.

Surely if they support several hard-coded themes, how hard is it to create 
another hard-coded theme if you have access to the source code?  I mean, if 
they support several themes already, it must be somewhat generic, right?


> And who really cares
> about that weird Ribbon menus? What extra enterprise functionality
> your customers would gain if you modify your tool bar to look like a
> huge horizontal bar with extra large icons?
>

If you have to ask, then you would not use the ribbon anyway.  Users will 
determine the success of the ribbon; from what I've seen, they are evenly 
split between loving it and not liking it.  You can't argue that a ribbon 
makes your app look modern, which depending on your audience, is the entire 
battle (productivity is not a concern to some people).


> 4. Coming to Source code, well...its a poor job too. Take a look at
> any of the MFC beta new controls' source code and you would know what
> I am talking about. The first prominent thing you can find is the
> abundant misuse of "friend class" feature, followed by the next misuse
> of "public data members".  Not to mention about the global data
> structures without a namespace or accessor functions.
>

That's too bad; Microsoft started this effort months ago, I would have hoped 
they would have cleaned up the code during that time.  No doubt with the 
proliferation of 3rd party frameworks, the code in the core MFC is (or was) 
much better than the what is in the 3rd party frameworks.


> 5. As for the controls themselves, are they efficient? Well...I am not
> sure - at least I was not impressed. May be I was wrong with this one
> - but many times I came across unnecessary flickering with controls
> when resized or re-layed out. May be there are functions inside that
> we can override to optimize this - but I could not easily find them.
>

Yup, the performance of BCGSoft is sadly lacking.  That's why I chose 
CodeJock  instead.  Again, I would have thought MS would have spent all 
these months improving it to be at least as good as CodeJock, but it doesn't 
sound like they did.


> 6. And are the controls extensible? Well, take a look at the property
> gird - it has hard coded property editors for spin control, combo box.
> Beyond that you cannot have your own in-place editors, such as check
> boxes (for true/false) or slider control (for integers). Nor could I
> find much support for extending the stock editors !!
>

Same as for the ribbon themes - they must support adding additional editor 
controls in the same manner as they created the original ones.



> 7. The BCGSoft website has offered samples demonstrating the use of
> few Grid controls such as report grid and multi-column tree view
> controls etc... But I could not find any Grid control at all inside
> the MFC beta !! Wondering if MFC beta is kind of "trial" version of
> BCGSoft control libray, where if you like the MFC then you should go
> and buy the full BCG Soft Control bar library.
>

Yes, Microsoft has clearly stated they did not license the entire library, 
and if you want the whole thing you need to buy the BCGSoft separately.


> All in all - the only real useful feature I can find in this version
> (for enterprise level software) is - the docking ability for windows.
> Beyond that the controls do not stand upto the level of MFC, nor the
> code does.
>
> Now having cribbed enough about this - lets put few points that could
> make the VC++ robust. Lets think about What we really want from VC++.
>
> The answer is simple: Lets have VC++ give all that the .Net is
> providing to its developers. In otherwords,
>
> 1. We need the ability to generate, compile and build VC++/Win32/COM
> dlls on the fly. We have been using VC++ compiler for so many years,
> they never had the thought of making it re-usable API or component,
> where as the .Net had this feature built in right from the startup.
>   Why dont we have our cl.exe (and all other apps that are
> responsible for compiling and generating the dlls) exposed as API?
> Note that the major power .net has is because of its meta data and its
> usage in reflection. We DO have metadata for native dlls too - in the
> form of type-libraries for COM. But we are limited in our reflection
> ability - we cannot dynamically create a COM dll in memory and load
> its types from another App. We NEED this ability.
>   This could bring a huge leap for VC++ developers. After all, today
> they talk about ASP.Net with code behind .net assemblies. If those
> bloated .net assemblies can bring ASP.net so much power, then imagine
> how much  power c++ native dlls could bring to the web applications.
>
> 2. We need all the latest controls the .Net is offering to its
> developers: Right from the layout panels to the Property Gird UI
> editors, Form design surfaces, Tray Icon notifiers, Visual Studio
> debug visualizers...all accessible as WTL controls or MFC/Win32
> controls. (Note that once we have the ability to generate C++ dlls on
> the fly this should become possible and easy.)
>    We need all the sleek looking Grid controls, report controls, mult-
> column tree controls, property grid controls, HTML surface controls
> (to bring the effect of styles/themes to our native applications, just
> like those website styles/themes) ...
>
> 3. More importantly - stop pushing managed C++. This alone could be a
> very big boon for all of us. Give us native XML parsers and do not
> deprecate the SOAP tool kit.
>
> These should be enough for now.
>

Heh, we sing the same song, you and I.  But I've stopped singing it.  The 
reason is there's no way Microsoft will invest in bringing .NET features 
into native C++, as native C++ is a shrinking market and they really want 
Windows apps to be managed anyway, as security is better.

I really appreciate your time in writing these opinions.  I've referenced 
them on a private VC++ newsgroup for MVP's, so the dev team at MS can see 
it.

-- David


0
dc2983 (3206)
1/17/2008 7:13:03 PM
> The  reason is there's no way Microsoft will invest in bringing .NET 
> features into native C++, as native C++ is a shrinking market and they 
> really want Windows apps to be managed anyway, as security is better.
>

Ditto.

---
Ajay

0
ajaykalra (6842)
1/18/2008 1:57:04 AM
"Ajay Kalra" <ajaykalra@yahoo.com> wrote in message 
news:230012A9-9AAD-4D59-93C1-D969592381ED@microsoft.com...
>> The  reason is there's no way Microsoft will invest in bringing .NET 
>> features into native C++, as native C++ is a shrinking market and they 
>> really want Windows apps to be managed anyway, as security is better.
>>
>
> Ditto.
>
> ---
> Ajay
>

I've was one of those C++/MFC die-hards.  A couple of months ago or so, I 
started dabbling with C#/WPF GUIs.  It's a night/day comparison - C#/WPF 
being the day.

Instead of hoping for an MFC miracle, I'll be working towards a general 
model for creating apps with a .Net GUI and a C++ backend for performance 
sensitive processing.

I agree that the big drive from MS is to get everything into managed apps in 
the near- and medium-term.

<crystal ball>

IMO, the long-term goal will be web apps as much as possible.  .Net will 
provide the platform security, web-centric applications will fight piracy 
and simplify distribution.

Web-centric apps will also move the world to a subscription model instead of 
the current purchase/support subscription model.  Properly packaged by 
marketing gurus, this will look like (and could very well be) a savings by 
removing the one-time up front charge.

</crystal ball>

I think the recent MFC update makes it pretty clear that there won't be a 
lot out there for MFC in the future.



0
1/18/2008 1:29:06 PM
"BobF" <rNfOrSePeAzMe@charter.net> ha scritto nel messaggio  A couple of 
months ago or so, I

> started dabbling with C#/WPF GUIs.  It's a night/day comparison - C#/WPF 
> being the day.

Yes, I also think that C#/WPF is great technology for presentation layer.

However, there are some reasons to still use MFC, like supporting and 
evolving old code base (which works well, so why rewrite to C#?). Another 
reason is the fact that - in general - MFC native apps tend to be faster 
(and smaller) than managed ones, at least on current hardware (for example, 
at startup, no need for JIT compiling is required, and no need to load the 
..NET framework "monster").

And C++ is still a very important player in the game, for example, to use 
multiplatform libraries (scientific libraries like Blitz++, several graphics 
engines - also open-source, like Coin3D or OpenSceneGraph, etc.). And also 
for some specific Windows-only stuff, like developing shell-extensions, I 
think that C++ is the way to go.

BTW: I also would like to congratulate to the OP who started this thread: 
his post is very interesting reading.

Giovanni


0
1/18/2008 5:17:49 PM
"BobF" <rNfOrSePeAzMe@charter.net> wrote in message 
news:O$uMeYdWIHA.3940@TK2MSFTNGP05.phx.gbl...
>
> "Ajay Kalra" <ajaykalra@yahoo.com> wrote in message 
> news:230012A9-9AAD-4D59-93C1-D969592381ED@microsoft.com...
>>> The  reason is there's no way Microsoft will invest in bringing .NET 
>>> features into native C++, as native C++ is a shrinking market and they 
>>> really want Windows apps to be managed anyway, as security is better.
>>>
>>
>> Ditto.
>>
>> ---
>> Ajay
>>
>
> I've was one of those C++/MFC die-hards.  A couple of months ago or so, I 
> started dabbling with C#/WPF GUIs.  It's a night/day comparison - C#/WPF 
> being the day.
>
> Instead of hoping for an MFC miracle, I'll be working towards a general 
> model for creating apps with a .Net GUI and a C++ backend for performance 
> sensitive processing.
>
> I agree that the big drive from MS is to get everything into managed apps 
> in the near- and medium-term.
>
> <crystal ball>
>
> IMO, the long-term goal will be web apps as much as possible.  .Net will 
> provide the platform security, web-centric applications will fight piracy 
> and simplify distribution.
>
> Web-centric apps will also move the world to a subscription model instead 
> of the current purchase/support subscription model.  Properly packaged by 
> marketing gurus, this will look like (and could very well be) a savings by 
> removing the one-time up front charge.
>
> </crystal ball>
>
> I think the recent MFC update makes it pretty clear that there won't be a 
> lot out there for MFC in the future.
>

G and Ian ... I should've been more clear on this last point.  I was 
referring to updates and new functionality when I said (typed) "there won't 
be a lot out there for MFC in the future".

Of course there will be plenty of MFC-oriented work for a very, very long 
time.  I just don't believe there will be much evolution for MFC as a 
technology.




0
1/18/2008 7:27:59 PM

> I think the recent MFC update makes it pretty clear that there won't be a 
> lot out there for MFC in the future.

It was clear to me many years ago. It made no sense for MSFT to invest any 
resources in VC++. It still doesnt. MC++ was really not needed. CLI is good 
but its usefulness is limited to current unmanged C++ environement, which by 
definition would not want to use .Net.

---
Ajay


0
ajaykalra (6842)
1/19/2008 12:31:57 AM
"BobF" <rNfOrSePeAzMe@charter.net> wrote in message 
news:u8jLBhgWIHA.4740@TK2MSFTNGP02.phx.gbl...
>
> "BobF" <rNfOrSePeAzMe@charter.net> wrote in message 
> news:O$uMeYdWIHA.3940@TK2MSFTNGP05.phx.gbl...
>>
>> "Ajay Kalra" <ajaykalra@yahoo.com> wrote in message 
>> news:230012A9-9AAD-4D59-93C1-D969592381ED@microsoft.com...
>>>> The  reason is there's no way Microsoft will invest in bringing .NET 
>>>> features into native C++, as native C++ is a shrinking market and they 
>>>> really want Windows apps to be managed anyway, as security is better.
>>>>
>>>
>>> Ditto.
>>>
>>> ---
>>> Ajay
>>>
>>
>> I've was one of those C++/MFC die-hards.  A couple of months ago or so, I 
>> started dabbling with C#/WPF GUIs.  It's a night/day comparison - C#/WPF 
>> being the day.
>>
>> Instead of hoping for an MFC miracle, I'll be working towards a general 
>> model for creating apps with a .Net GUI and a C++ backend for performance 
>> sensitive processing.
>>
>> I agree that the big drive from MS is to get everything into managed apps 
>> in the near- and medium-term.
>>
>> <crystal ball>
>>
>> IMO, the long-term goal will be web apps as much as possible.  .Net will 
>> provide the platform security, web-centric applications will fight piracy 
>> and simplify distribution.
>>
>> Web-centric apps will also move the world to a subscription model instead 
>> of the current purchase/support subscription model.  Properly packaged by 
>> marketing gurus, this will look like (and could very well be) a savings 
>> by removing the one-time up front charge.
>>
>> </crystal ball>
>>
>> I think the recent MFC update makes it pretty clear that there won't be a 
>> lot out there for MFC in the future.
>>
>
> G and Ian ... I should've been more clear on this last point.  I was 
> referring to updates and new functionality when I said (typed) "there 
> won't be a lot out there for MFC in the future".
>
> Of course there will be plenty of MFC-oriented work for a very, very long 
> time.  I just don't believe there will be much evolution for MFC as a 
> technology.

Thats how I feel. Its just wasted resources in part of MSFT to even think 
about it. Keep in mind MSFT has already retired WinForms in favor of WPF.

---
Ajay

0
ajaykalra (6842)
1/19/2008 12:37:09 AM
Reply:

Similar Artilces:

MFC Serialize and CAsyncSocket
Hi !!! Does anyone know how I can transmit a full class thru a network using CAsyncSocket ? I think that the serialize method from CObject must be used but seems to work with files and not with networking. Thx for your answers. Try attaching a CSocketFile or CArchive to the CSocket Ali R. "Bonnel Maxime" <bonnel.maxime@wanadoo.fr> wrote in message news:bv3i2u$s53$1@news-reader1.wanadoo.fr... > Hi !!! > > Does anyone know how I can transmit a full class thru a network using > CAsyncSocket ? I think that the serialize method from CObject must be used > but s...

learning MFC #2
Hi there, where can I find some online tutorials to learn MFC programming? Thnx alot! "Marc Schodermayr" <SchodMC@muv.com> wrote: >Hi there, > >where can I find some online tutorials to learn MFC programming? Check the Scribble tutorial. It's in your MSDN library, and online at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vctutor98/html/_gs_build_scribble.2c_.step_5.asp -- Tim Slattery MS MVP(DTS) Slattery_T@bls.gov This site also has gud material: http://www.softlookup.com/tutorial/vc%2B%2B/ Vijay "Marc Schodermayr" <...

MFC Application has encountered a problem and needs to close. HELP
This is driving me nuts. Whenever I run my program in release configuraiton it always crashes with the above error message offering me an option to send a message to Microsoft. I have discovered it is an access violation (code 5). Whenever I run the program in debug configuration it runs OK. I have two main questions: 1 How can the program behave so differently in the two configurations? I can find no explanation of this in the help files. 2 How can I get useful information about the access violation? I cannot save the crash dump produced which the exception handler offers to send to ...

Multi-threading and CMap / CList MFC classes
Hello MFC gurus, (1) Is it legal to allocate (using "new" operator) a CMap / CList object in one thread and destoyed it (using "delete" operator) in another one? (2) Is it legal to access a CMap / CList MFC object in different threads (using a "mutex" to control access to the shared object)? Thanks in advance Best regards, Olivier. Also, FYI, I use MFC as shared dll + multi-threaded CRT (dll) Olivier. "Olivier" <toon@toonworld.com> a �crit dans le message de news: ON%23TDbayKHA.6140@TK2MSFTNGP05.phx.gbl... > Hello...

CCommandLineInfo and MFC GUI
Greetings, I am trying to write an MFC-based application which can be run via command line. It should not pop up GUI if following line is executed: C:\>myapp.exe /nogui It should execute normally when following line is executed: C:\>myapp.exe I am able to parse command line arguments using CCommanLineInfo class. If user executes the program from command prompt with /nogui option then application should run code and it should pop up messages as to its progress and never the main program GUI. After it has done executing code it should gracefully exit. Need some pointers on how to...

MFC Sample Programs for Visual Studio 2008?
I'm trying to find an example MFC program that demonstrates use of the Tab Control (CTabCtrl). Looking in MSDN, I find references to an example named "Fire...", but I cannot locate the actual download. Anybody know where this, or another Tab Control use example program can be found? Thanks for any suggestions. "PvdG42" <pvan@toadstool.edu> wrote in message news:%230pR%23ABFJHA.616@TK2MSFTNGP06.phx.gbl... > I'm trying to find an example MFC program that demonstrates use of the Tab > Control (CTabCtrl). > Looking in MSDN, I find references to ...

How Do We Insert a VC++ Routine in a MFC program?
I need to do this because I do not know how to convert the VC++ routine into MFC. However, the routine does compile (and executes with main() included) when we do it with Visual Studio 6.0 (MFC). So, assume that we have a routine hello(string bertolucci); How do we call this routine from inside a MFC program? Thanks! Maria hello("string") ; ;-) Seriously can you provide more information? Have you declared your hello() function within the class you are trying to call it from? Is the function one of yours, or is it a 'system'; API call. If it is an API call, have you inclu...

Migrating from Beta Edition of Access 2003 to Access 2003
Hi, I designed a database for a customer who was initially using the Beta Edition of Microsoft Office 2003 Professional. Recently, they bought Microsoft Office 2003 Professional and installed it on their computer. However, now the InvoiceForm and the EditDeleteInvoice form do not show the total amount like they did with the Beta Edition. Neither does the rptInvoiceStatement show the total amount, however it did display the total amount with the Beta Edition. There have been no changes made to the database application itself which is in Access 2002 format. The InvoiceForm has two subforms o...

New Version of MFC for VC2005?
It appears that SQL Server 2008 installs a new side-by-side mfc version: 8.0.50727.1833 The one included with SP1 was 8.0.50727.767 Trouble is my application now crashes when that one is loaded with a Unicode release build. How can I set up a manifest that insists on loading the one I distributed with my application. I tried setting up a manifest that said: </dependency> <dependency> <dependentAssembly> <assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50727.762' processorArchitecture='x86' ...

mfc project not compile in visual studio 2008
I made a mfc project using wizard in visual studio 2008 and it didn`t compile,. i didn`t add anything, just made it as it should be. i tried changing _WIN32_WINNT and WINVER 0x0600 but it just resulted in another errors. i also reinstalled my vs 2008, but it didn`t help. For more informations i have win xp sp2 and freshly installed microsoft visual studio 2008 in a default way. errors: 1>stdafx.cpp 1>c:\program files\microsoft visual studio 9.0\vc\atlmfc\include\winnt.h(3019) : error C2146: syntax error : missing ';' before identifier 'ContextRecord' 1>c:\progr...

Portfolio Review-Performance Section
Running Money '04 and its great. But, Performance section of Portfolio Review is not showing "YTD" column for: My Portfolio or DJIA or SP500. It is showing "Last 12 Months" figures, in these columns. Not sure what I messed up. If a resolution is previously available, what is navigation to solution. Thanks. ...

CommandLine argument in MFC
Hi all, I have dialog based application. Now i want to pass command line arguements to this application. How do i go about it. What is the best way of getting the arguements?? Also i will be starting this application using the api CreateProcess() and pass my arguement from it.??? So how do i go about it?? kunal >I have dialog based application. Now i want to pass command line arguements >to this application. How do i go about it. What is the best way of getting >the arguements?? I make use of the global arguments that the MS C++ run-time provides - __argv (__targv) & __...

HTML in MFC Application?
Hi all I have created a MFC SDI application. i have derived the view class from the CHtmlView class and used the LoadFromResource() to load the html page into the view. Now there were quite a few things that i wanted to stop for ex: -------) stop the context menu to be displayed when mouse is right clicked on the html page. -------) stop the mouse selection for the html content. -------) stop the mouse cursor change over the static text. All these problems are solved by adding some code in the html page inside the <SCRIPT> tag. There is one more behaviour that i want to stop: &qu...

how to set different colors to track changes author reviewer
I want different colours to be set for track changes i.e first colour by author another colour by reviewer and yet another colour when the author reviews the replies given by the reviewer ...

System Calls from MFC Application
using system() command from mfc application, the black screen pops-up before my dialog box is very annoying, how do I automatically minimize it or close it and only show my dialog window? Thanks Instead of using system() , use any of the following API's. CreateProcess() ShellExecute[Ex]() -- Cheers Check Abdoul [ VC++ MVP ] ----------------------------------- "Arun" <arunkk@yahoo.com> wrote in message news:081201c361f9$60b5bd20$a401280a@phx.gbl... > using system() command from mfc application, the black > screen pops-up before my dialog box is very ann...

Beta Tester
How can my organization become an official CRM beta tester?? Gary Graves Infragistics, Inc ...

Styles change when someone reviews a document and returns it
Using Word 2007, I'm creating a template that will be used for writing policies. Formatting has become an issue though. If I use the default MS Word styles, the formatting of the document will sometimes change if the doc is sent to someone else for review and that person then returns the document with edits. For example, a text line will no longer be flush with the Heading 1 line above. Is that because that reader's style specifications for Heading 1 might differ from mine even though the style names are the same? If I rename the MS Word styles (e.g., CIP-Heading ...

OT: MS FixIt Centre Beta
Any one tried the new MS Fix It Centre Beta? Any comments? -- Annail�s ...

MFC 7 DDE problem
This is a multi-part message in MIME format. ------=_NextPart_000_00C1_01C3FF17.CEA81B00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MFC 7 has a bug in WM_DDE_EXECUTE handler of CFrameWnd lstrcpyn(szCommand, lpsz, _countof(szCommand)); line is missing. This is why when the user double-clicks on the Document associated with = app in WindowExplorer nothings happens. Microsoft recommends workaround by implementing WM_DDE_EXECUTE handler in app's CMainFrame and copying there the missing line. Unfortunately it solves the problem only i...

Compile error with Console App using MFC
Hello, I'm get the following compile errors when trying to build an MFC console application in release mode using Visual Studio .NET 2003 Professional C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\atlmfc\include\afxwin2.inl(1034) : error C2039: 'Enable3dControls' : is not a member of 'CWinApp' C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\atlmfc\include\afxwin.h(4289) : see declaration of 'CWinApp' C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\ostream(604) : fatal error C1903: unable to recover from previous error(s)...

Pub 2007 beta > Pub 98 > Pub 97 conversion
OK, I know I know...this is a very old topic. I've read thru some of the older threads from years back but haven't seen anything very recent regarding the ability to do this type of conversion. Probably because I'm the only one left on the planet who needs to know how it can be done. But sometimes as time goes on solutions appear. Here's hoping! I just can't believe that this is a dead end. I have over the years been able to convert just about everything I needed to convert but this project has me stumped. Here's what I have been able to do thus far. The original fil...

MFC project with my classes
I have got a project that uses MFC. I want to expand the functionality of the project by adding a few of my own classes to it. But I don't know where should I create objects of my new classes so that I can access them, I know the WinMain function resides in CWinApp class and my project has a class inherited from the CWinApp class, but where should I define my own objects I can't figure it our. Can anybody help? Adrian wrote: > I have got a project that uses MFC. I want to expand the functionality > of the project by adding a few of my own classes to it. But I don't > kno...

Vista/MFC 4.2 OnUpdateRecentFileMenu() quirk/bug
Hi, I'm testing a Visual C++ 6/MFC 4.2 app on Vista. I notice some (not all) of the items in the MRU list are blank. 1) Has anyone else noticed this? 2) Is there an OS update that fixes/will fix this? More detail: - copying mfc42u.dll from my XP machine to the app folder on the Vista machine solves the problem, so I suspect a bug in the Vista version of the dll. - when I step into CRecentFileList code I can see the paths in the member array is fine. - calls to GetDisplayName() return empty strings for the problem files. ...

Bought Office 2008 Beta and now it says it's about to Expire
Anyone seen this? And if so, what can I do Hello Jim, Come on, you're kidding us aren't you?: you say you "*bought* Office 2008 beta"! If you're telling the truth you have been absolutely *conned*. There has been no public beta release of Office 2008, for sale or otherwise. Therefore, your copy of a beta MUST have been stolen. It originated, ultimately, in someone violating the terms of their non-disclosure agreement with Microsoft. That is rather serious. There may be legal consequences of acquiring such a copy and you may well feel obliged to report the seller to ...

is MFC
I am making a client for a server and i would like to know if if MFC is best to use r is .NET a better solution for this and also i would like to know if MFC is outdated and only used for existing applications. This question pops up every once in a while and, of course, the answers are always opinionated, but from what I understand MFC will be supported for some time to come. If you are creating a native Windows UI based application my opinion is that MFC or ATL would be great platforms to continue using. There are lots of library functions and examples for code available. Also, usi...