Re: Nonsence about MFC

From: Bob Wolfe (rtwolfe_at_flexus.com)
Date: 09/22/04


Date: Wed, 22 Sep 2004 15:25:52 GMT

Robert Wagner <robert@wagner.net.yourmammaharvests> wrote:

>On 19 Sep 2004 20:04:12 -0700, riplin@Azonic.co.nz (Richard) wrote:
>
>>Robert Wagner <robert@wagner.net.yourmammaharvests> wrote
>>
>>> >With Micro Focus, one could use Dialog System. No OO.
>>> >Or Flexus SP2. No OO.
>>>
>>> Same for Fujitsu's PowerCobol. I could be wrong, but I strongly
>>> suspect all three are written in C++ and are using MFC.
>>
>>Yes, you could well be completely wrong.
>>
>>According to Bob Wolfe, posting on this very group (so it can be
>>determined easily for those that prefer to use facts rather than
>>opinions):
>>
>>""" sp2.dll screen handler is written in C """
>>
>>Both SP2 and Dialog system date from before MFC was available. This
>>makes your claim unsupportable. Even a cursory glance at facts should
>>have shown you that it wasn't viable.
>>
>>> I say that
>>> because controls look and behave identically. Not sorta-kinda the
>>> same.
>>
>>You don't seem to know much about MFC, or indeed Windows at all. MFC
>>is just a thin OO (some might say: sorta OO) wrapper around the
>>standard Windows controls. They all look the same because they are
>>_Windows_, regardless of whether they are MFC.
>
>The Windows API doesn't support things like ListBox, ComboBox and
>scroll bars. That functionality is supplied by MFC (and VB and Swing).
>How do SP2 and Dialog mimic MFC so closely?
>
>Bob Wolfe: please ring in with the answer.

All of the above are Win32 controls.

....but way back in the early 1990's many of our customers wanted
bigger, better, faster or fancier type controls. Well......it seemed
that writing custom controls ourselves was a yeoman's task and
possibly an exercise in futility. Obviously, everyone would have very
unique needs for various types of controls. Therefore, we decided
that Microsoft's VBX control approach showed promise and began
supporting that.

Eventually, with the advent of the 32 bit version of Windows,
Microsoft introduced 32 bit OLE and OCX (Active X) controls, which
were even better.

So our VBX support evolved into OCX and OLE automation support. This
approach seems to have worked very well as it offers the opportunity
for a programmer to use one of tens (perhaps hundreds) of thousands of
unique user interface and non-user interface controls. It really
opened up a huge set of possibilities for enhancing one's COBOL
program.

The OLE automation also allows for the control of Microsoft Office
applications which seems to be of great interest as well.

Bob Wolfe
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When replying by e-mail, make sure that you correct the e-mail address.
Check out The Flexus COBOL Page at http://www.flexus.com



Relevant Pages

  • RE: Font Object is not shown in VB5...
    ... Support for Your Projects> ... Internet Explorer simply loads the Windows Forms control itself and treats ... Windows Forms team did a full test cycle on hosting Windows Forms controls ... as COM controls in MFC 7.1¡ªthe version of MFC that comes with Visual ...
    (microsoft.public.dotnet.framework.interop)
  • Re: Placing a .NET UserControl in a COM type "Wrapper"
    ... Windows Forms only supports using Windows Forms controls ... > ActiveX controls and we do not support CoCreateInstance of Windows Forms ... Display a Winforms Form from an unmanaged application such as ...
    (microsoft.public.dotnet.framework.windowsforms.controls)
  • Re: Compiler features
    ... where payroll is becoming too complicated to do manually any more, ... API, Windows Forms, MFC, .NET and OLE. ... is the support for a data base and ODBC... ...
    (comp.lang.c)
  • HOW TO: Does C++ support ASP.Net web application development?
    ... MFC ActiveX Control ... Windows Control Library ... Does it therefore follow that C++ .Net does not support the creation of ASP.Net Web applications? ...
    (microsoft.public.dotnet.languages.vc)
  • Re: communicating netween applications
    ... most programs use the standard controls provided by Windows. ... except I use MFC calls. ... >>> would be the same everytime the other app and my app are run. ...
    (microsoft.public.win2000.developer)

Loading