Very Simple Question!!!

[needaname16]

Hi

I am relatively new to normal Windows Applicaitons in C++, I have gained a basic understanding of the interaction between forms and member varaibles and message maps. I have been able to set text to an text box control ok, but I am having trouble disabling a text box. Here is an exert of the code:

// m_TextEdit is a member variable of Class CEdit

// In the Menu Item in the OnClicked Event

// CInfoDlg is the Class for the Dialog

CInfoDlg Dlg;

Dlg.m_TextEdit.EnableWindow(FALSE):

if (Dlg.DoModal() == IDOK)
{
// Some Code follows here
}

When I do this the text box is still enabled. Any suggestions

Needaname16

[CornedBee]

While the dialog box is not shown, the edit control doesn't exist in reality, there is only the MFC container (CEditControl). A call to EnableWindow will therefore have no effect. Call this function in your dialog's OnInitDialog function (you may have to overwrite it). If the dialog box should always or initially be disabled, you can also specify it as a property in the dialog editor.

[CornedBee]

I already wrote that, parksie, but I deleted it again. He did not say normal windows programming. He said normal "Windows Applicaitons" (whatever that is :) ), so he is right. Without using Spy++, you'll probably not be able to distinguish an API app from a MFC app. (Except some...)

[parksie]

Normal windows applications then, more or less the same thing.

Either way, MFC isn't the way the core Windows developers do things.

[CornedBee]

But it is for example the VC++ developers do things :)

[parksie]

It seems that way :)

The Win32 developers are all hardcore C addicts :p

As far as MFC goes, I have no quibble with it when it's used in its place, which is pretty much DB access and anything that fits exactly into the Document/View paradigm (which I don't like, and I'm not the only one :D).

However, I stick to my argument that you should learn the real way first, and then choose MFC if you want. Otherwise you have slightly less chances than the snowball's of working out how to use it effectively.

[CornedBee]

The Win32 developers are nice people (uuhh...:rolleyes: ) who care for relics from C and don't want to exclude them from the "benefits of windows" :rolleyes:
;)
If the Win API was a class library, it would a) look like MFC so you'd since long been programming only for linux and b) hinder anyone that uses a function style language (pascal, C) from programming windows. And compatibility would be another problem. The COM is way younger than the WinAPI.

[parksie]

Yep. C is still an insanely compatible language :)

Actually, it wouldn't look like MFC - the reason that is so ugly in places is because it's an adaptor over a non-OO methodology.

Admittedly, a nice OOP C++ interface would be bloody nice and dead easy to program for, but it would remove compatibility not only with non-C++ users, but also with anyone that didn't use MSVC++ (name mangling).

I'm excluding COM because it's not fast enough to use for event handling.

[needaname16]

hmmmmmm......

That was an interesting discussion above, I started with straight fortran, basic, c and pascal (doing firmware based development). Just recently I have been learning the Visual tools by Microsoft and working with windows. Can someone enlighten me on how to get information and use API to develop Windows applications. I agree with the discussion above and would like to improve the method I use to do Windows programming.

Thanks :)

Needaname16

[parksie]

Needaname16: Go to MSDN (msdn.microsoft.com) and download the Platform SDK. That gives you EVERYTHING you need :)

CB: Name mangling is only a small part of the problem.

Look up ABI (Application Binary Interface) to find the sorts of problems you get. As a quick few off the top of my head:

Name mangling
Structure alignment
Virtual function pointer tables

[CornedBee]

Structure alignement is not a problem, you can set that for every compiler I know.
vtables are used for COM too, so that can't be a problem.

But I still agree, it's just not standardized enough to make it possible. (Import libraries...)

[parksie]

Does COM use the actual C++ vtables? I'm sure that's an implementation-definable detail (i.e. you can put it wherever you want as long as the code works).

Eventually things like this will all get sorted out (c.f. .NET :p)

[CornedBee]

Yes, I think it does.

[parksie]

So how would you use it with something like Borland then? Surely they'd have a different in-memory layout.

[CornedBee]

Not necessarily, vtables are rather simple. You can emulate them using C (look in some COM headers, maybe DirectX, to see what they do exactly). To do this, you define a struct that has the additional member pVTable of type SOMESTRUCT*. Then you define SOMESTRUCT as collection of function pointers. Since interfaces never have data members, the vtable is always at the same location.

It might be more complicated for real classes, but with the pure virtual COM interfaces it seems to work.

[parksie]

I know you can do it in C because that's what compilers used to do, convert C++ to C and then use a C compiler on it :)

Just because they're simple doesn't mean they're compatible.

[CornedBee]

But this is what a COM call is converted to:

mov eax, _IMyInterfaceOffset$[ebp] ; local var or function parameter
push ecx ; parameters
push 4 ; more parameters
push eax ; this pointer
mov ecx, [eax] ; first data member of IMyInterface to ecx
; this is the vtable
call [ecx + <function offset>] ; do the call

e.g. Blt is the 5th function of the interface IDirectDrawSurface4 and has the offset 20 (= 5*4)

[parksie]

As you just proved to me, that's dependent on internal layout.

[CornedBee]

But this is what a COM call is converted to:

mov eax, _IMyInterfaceOffset$[ebp] ; local var or function parameter
push ecx ; parameters
push 4 ; more parameters
push eax ; this pointer
mov ecx, [eax] ; first data member of IMyInterface to ecx
; this is the vtable
call [ecx + <function offset>] ; do the call

e.g. Blt is the 5th function of the interface IDirectDrawSurface4 and has the offset 20 (= 5*4).

Such code is created by VC++6, and it can't be different for Borland cpp builder or else the code wouldn't work.
Also, the compiler doesn't know if it is compiling a COM object, so they just can't get a special treating.

[parksie]

Originally posted by CornedBee
Such code is created by VC++6, and it can't be different for Borland cpp builder or else the code wouldn't work.
Also, the compiler doesn't know if it is compiling a COM object, so they just can't get a special treating. Somehow I get the feeling that we're talking two different things here.

I'm pointing out that just because MSVC has the vtable first doesn't mean you have to. I suppose it just means that any compiler that professes to create COM DLLs does it that way for everything.

[CornedBee]

I mean that every compiler that is able to create COM objects without some special option needs to do it this way.

[parksie]

Yeah, but not every compiler professes to be able to create COM DLLs (GCC for one).

[CornedBee]

Yeah, but gcc was developed for unix-like systems, not for windows. A linker that is able to create dlls may enable gcc to create COM objects.

[parksie]

The linker has nothing to do with C++ class layouts - that's up to the compiler.

But the core point of what I'm saying is, you cannot guarantee it will work with COM unless the compiler says it can.

[CornedBee]

Yeah, exactly.