CreateWindowEx - "ThunderFormDC"
CreateWindowEx - "ThunderFormDC"
CreateWindowEx - "ThunderFormDC"
CreateWindowEx - "ThunderFormDC"
CreateWindowEx - "ThunderFormDC"
CreateWindowEx - "ThunderFormDC" CreateWindowEx - "ThunderFormDC" CreateWindowEx - "ThunderFormDC" CreateWindowEx - "ThunderFormDC" CreateWindowEx - "ThunderFormDC" CreateWindowEx - "ThunderFormDC" CreateWindowEx - "ThunderFormDC" CreateWindowEx - "ThunderFormDC"
CreateWindowEx - "ThunderFormDC" CreateWindowEx - "ThunderFormDC"
CreateWindowEx - "ThunderFormDC"
Go Back  Xtreme Visual Basic Talk > > > CreateWindowEx - "ThunderFormDC"


Reply
 
Thread Tools Display Modes
  #1  
Old 09-11-2004, 12:39 PM
Mathimagics's Avatar
MathimagicsCreateWindowEx - "ThunderFormDC" Mathimagics is offline
Algorithms 'R' Us

Forum Leader
* Guru *
 
Join Date: Jun 2002
Location: Canberra
Posts: 4,159
Default


Hello .... I missed this discussion, but I see it all happened as I was heading overseas, so didn't see it until now .... I was looking (again) at atoms ....

None of the posts mentioned one salient fact!

The class ThunderFormDC only exists in the IDE, of course... at runtime, you'd need to use ThunderRT6FormDC, right?

Otherwise, assuming you have allowed VB to open the private class library (which an EXE will do as soon as it first creates a Form), there should be no inherent obstacle to creating windows from any registered private classes ...

What MIGHT complicate things is that almost all VB window classes are themselves derived from a "master class", VBBubbleRT6 ...

But, any hope of emulating VB window behaviour is going to be very tricky - the class alone will not breathe functional life into your window, it's all the various interacting message handlers that do the real work ... by just relying on DefWndProc handling, you are probably running a dead window ....

All hypothetical, of course ...

What I wanted here, really, was how to tell what an atom value, like C01A .... means

I hope it's in here somewhere after all this effort!
__________________
Cogito, ergo codo

Last edited by OnErr0r; 09-11-2004 at 07:53 PM. Reason: Linked old thread
Reply With Quote
  #2  
Old 09-11-2004, 04:42 PM
pikzel_RCreateWindowEx - "ThunderFormDC" pikzel_R is offline
Contributor

* Expert *
 
Join Date: Jul 2004
Posts: 484
Default VBBubbleRT6 base class

Quote:
Originally Posted by MathImagics
Otherwise, assuming you have allowed VB to open the private class library (which an EXE will do as soon as it first creates a Form), there should be no inherent obstacle to creating windows from any registered private classes ...

What MIGHT complicate things is that almost all VB window classes are themselves derived from a "master class", VBBubbleRT6 ...What I wanted here, really, was how to tell what an atom value, like C01A .... means
Hi MathImagics,

You've mentioned that VBBubbleRT6 "master" class before in regard to global sub-classing and in regard to a base class that "picks up anything" and wondered "has anyone tried this?" in this post:
http://www.xtremevbtalk.com/837029-post9.html

So I'm also wondering also has anyone actually tried this successfully(?) or tried "creating windows from any registered private classes ..." (like the VBBubbleRT6!).

The only information/documentation I could find on VBBubbleRT6 is from O'Reilly:
http://www.oreilly.com/catalog/subho...pter/ch01.html

I was wondering if VBBubbleRT6 is officially documented anywhere in any Microsoft docs or is there any other references for this anywhere?

I found a few references for the ThunderRT6Main class, but the O'Reilly chapter says that the VBBubbleRT6 class is the one responsible for forwarding messages to the appropriate window, so is that the source of the support for the "message pump" that all VB forms have built-in?
Reply With Quote
  #3  
Old 09-11-2004, 06:46 PM
Mathimagics's Avatar
MathimagicsCreateWindowEx - "ThunderFormDC" Mathimagics is offline
Algorithms 'R' Us

Forum Leader
* Guru *
 
Join Date: Jun 2002
Location: Canberra
Posts: 4,159
Default

I think I can shed some light on some of those questions - coincidentally, I just dragged out my own copy of Stephen Teilhet (the O'Reilly book in question) a few days ago, and it's amazing what a difference a year (since I last looked) makes ...

I'm feeling particularly generous as I have finally unlocked the secret of one very hard-to-pin-down atom (and realise now why it could never be found with Atom API!)

I'll be back with those items, and more, following these important messages
.....
__________________
Cogito, ergo codo
Reply With Quote
  #4  
Old 09-11-2004, 07:52 PM
Mathimagics's Avatar
MathimagicsCreateWindowEx - "ThunderFormDC" Mathimagics is offline
Algorithms 'R' Us

Forum Leader
* Guru *
 
Join Date: Jun 2002
Location: Canberra
Posts: 4,159
Default

VBBubbleRt6

Master class ... a better term is "base class". All Thunder classes are superclasses (aka derived classes) of this class.

A base class is a template to define common functionality. New classes are derived from the base class with variations like perhaps a different style, etc.

As Teilhet says, if you look at runtime windows, all Thunder... windows, except ThunderRT6Main, will have the same window procedure, which is defined in the base class.

VBThunderRT6Main

I call it the "Forms Manager", as that's what its primary purpose is - it's a hidden top-level window, the first created by an EXE, and it has its own window procedure. One of its functions is to act as an Owner for all your Forms (each is a ThunderRT6FormDC top-level window), so that when you minimise your main window, it minimises the others as well, and keeps them in front of the main one, etc... so they don't get lost when you activate the
main form, etc, etc

VBFocusRt6

I disagree with the text on that - I think this little fellow, as its name
implies, helps support the GotFocus and LostFocus events. These aren't supported for lightweight controls, and I can assure you that lighweight controls work fine without the Forms Manager being present, in any case.

Message Pump

All Win32 applications (that show windows) have to collect ("pump") their own messages. The system only delivers them as far as the message queue, and there is a queue for each thread that creates windows. VB6 runtime is single-threaded so we have the basic, monolithic Win32 application setup.

The pump is simply wrapped for you in the startup code. Instead of having
to write your own WinMain, the VB runtime provides one for you and automatically starts running it when your application starts up. This function is a lot more complex in a VB6 app than in other less "managed" languages, and is provided by the msvbvm60 ThunRtMain function. Your app enters that and never leaves until the last window is destroyed and/or the process terminated.

The pump should not overly concern you - who is running it doesn't matter, as it is only a means by which messages get past the front door, and delivered to the individual apartments! (i.e. the windows created by this
thread). The pump itself doesn't need to know your new window exists, just the action of it removing a message and calling DispatchMessage will then deliver it to the window it was posted to.

Documentation

Ha! This is exactly the sort of information you will never find volunteered by the vendor, for all the usual reasons (a few of which, it must be said, are quite understandable, although still frustrating)

The runtime is a highly sophisticated and heavily [b]managed[/u] environment - stepping outside the white lines crosses an awkward boundary in many respects, from a support point of view.

The base information is all there, fortunately, you just need to work hard at it, and draw inferences (lots and lots and lots ....) ... and visit web sites where people are beavering away doing likewise.

But always start from basics, is my advice, and the MSDN CD, despite its age, is still a treasure trove for understanding Win32.

Start with WinMain, then go into Tech Articles/Platform/Windows Management section, and learn by heart "pentateuch" articles like "Win32 Windows Hierarchy and Styles", and "Window Classes in Win32". You'll see related articles in the same section of interest about the "architecture" of a simple Win32 application .... inside all the gift wrapping a VB6 exe is still just that ....

.... to be continued
__________________
Cogito, ergo codo
Reply With Quote
  #5  
Old 09-11-2004, 08:26 PM
Mathimagics's Avatar
MathimagicsCreateWindowEx - "ThunderFormDC" Mathimagics is offline
Algorithms 'R' Us

Forum Leader
* Guru *
 
Join Date: Jun 2002
Location: Canberra
Posts: 4,159
Default

Rolling Your Own VB Windows

In one sense creating your own VB "Form" window is easy ... your process can create windows of any class it has registered, they belong to your application.

Remember too, that you can dynamically create the controls themselves, with CreateObject:
Code:
Set B = CreateObject("VB.CommandButton") Set F = CreateObject("VB.Form")

It's the difference between creating a Form object, and creating a "form-window" that is, I think, the chief obstacle to "private form" creation.

You can create your own windows at any time, either from system classes (pre-registered) like "Edit" and "button", from public registered classes like the Common Controls in ComCtl32 - eg SysTreeView32 - and they will inherit the default window procedures that are defined for that class.

And you can also create instances of your application's private classes, in exactly the same way.

But there is an important difference to consider. Creating your own instance of the ThunderRT6FormDC window class is, I repeat,
quite straight-forward. But is that the same as creating your own private Form?

The answer is no!!!! A Form is a much more complicated beast, it is a COM object, and the window it encapsulates is just one of many "properties" associated with the object.

Make no mistake, the VB6 GUI is not just a wrapper for window messaging, it's the "Biggest Class Factory on Earth", it's COM, COM and more COM.

The functionality of a Form cannot be handled by message handling alone, there are complex project-specific data structures that are associated with the objects, and other considerations.

A system class, by design, is "re-entrant", in that its functionality is entirely encapsulated in the default window procedures.

A mere copy of a "form" window is just a hulk - probably worse, as it will be full of traps - the VB-supplied message handlers it inherits from the base class must transparently handle these windows that were not created by the runtime library, which might be OK, but since they have no object association, sooner or later something must go bang ....

In other words, you're better off using CreateObject("VB.Form") to create a private Form (and that is worth experimenting with, as it gives you a blank but valid object and window together).


Rolling Your Own VB Window Classes

Creating your own private "Form" class might still be viable, through a method called "superclassing" - which is what VB does, I think, itself.

I won't even try to describe it, because happily, Mr Teihert has a very thorough chapter devoted to the subject. Refer to Chapter 7 of your O'Reilly book, where Mr Teihert appears to be doing something along the very lines Gilad was describing ... superclassing ThunderRt6FormDC

The sample project on the CD certainly looks interesting .....

Just bear in mind that occasionally they DO get things wrong, it's bound to happen when writing a tome like that ..... always verify observations that you intend to turn into assumptions .... but you will see from some of the commented-out code that he was conducting similar experiments ...


And on that note, phew... that'll do, I reckon!


Who wound me up again?

Carry On!
__________________
Cogito, ergo codo

Last edited by MathImagics; 09-11-2004 at 08:37 PM.
Reply With Quote
  #6  
Old 09-11-2004, 08:40 PM
pikzel_RCreateWindowEx - "ThunderFormDC" pikzel_R is offline
Contributor

* Expert *
 
Join Date: Jul 2004
Posts: 484
Default The classes behind VB forms

Quote:
Originally Posted by MathImagics
Phew... that'll do, I reckon! Who wound me up?
Carry On!
Sorry to wind you up, but that was most interesting. A treasure trove of info indeed!

I am definitely going to have to try and find that book and read Chapter 7, but you've really done a good job of summarizing what is happening behind the scenes with the hidden classes that generate/mange VB forms.

I almost feel this should be posted on a your web site or Tutor's Corner or something. I definitely will keep this thread bookmarked.

Thanks much!
Reply With Quote
  #7  
Old 09-12-2004, 02:25 AM
Mathimagics's Avatar
MathimagicsCreateWindowEx - "ThunderFormDC" Mathimagics is offline
Algorithms 'R' Us

Forum Leader
* Guru *
 
Join Date: Jun 2002
Location: Canberra
Posts: 4,159
Cool

Cheers, pikzel_R, I was thinking towards the end there that I'd half-written a tutorial on the subject ....

Thanks for the kind endorsement ... I will make an effort to develop it into just such a thing .....

.... meanwhile, through all that, I finally worked out the "secret of the atom", after much pain and general banging of heads (on walls) .... those "classname identifiers" like "C0A0", they can't be "looked up" with any "atom API", of course, because they were not created that way .... they belong to a special, and very private, atom table, which belongs exclusively to the window class registration system.

That's why there is no ClassNameFromClassAtom API, because the window class registration system doesn't actually need such a function ...

You can do the inverse, ClassAtomFromClassName, quite easily, but only if you have a handle to an actual window of that class ...
Code:
Atom = GetClassLong(hWnd, GCW_ATOM) ' -32
Another useful value returned by GetClassLong is the handle of the module that registered the class to which a window belongs:
Code:
hModuleClassOwner = GetClassLong(hWnd, GCL_INSTANCE) ' -16

The VB6 runtime "Thunder" class atoms, while looking superficially predictable, will vary from system to system, and perhaps from app to app...

So a runtime identification function would be handy ....


Hmmm .... just writing this down has given me an idea - I'll need to conduct some atomic experiments ... fission or fusion, though, that is the question ...

Ha, ha, we'll call it "The Puttenham Project" (the sequel to "The Manhattan Project", )

... Stand WELL back now, Southern England, stay behind the ropes, please ....

.... just in case it all goes BANG ....
__________________
Cogito, ergo codo
Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off

Forum Jump

Advertisement:





Free Publications
The ASP.NET 2.0 Anthology
101 Essential Tips, Tricks & Hacks - Free 156 Page Preview. Learn the most practical features and best approaches for ASP.NET.
subscribe
Programmers Heaven C# School Book -Free 338 Page eBook
The Programmers Heaven C# School book covers the .NET framework and the C# language.
subscribe
Build Your Own ASP.NET 3.5 Web Site Using C# & VB, 3rd Edition - Free 219 Page Preview!
This comprehensive step-by-step guide will help get your database-driven ASP.NET web site up and running in no time..
subscribe
CreateWindowEx - "ThunderFormDC"
CreateWindowEx - "ThunderFormDC"
CreateWindowEx - "ThunderFormDC" CreateWindowEx - "ThunderFormDC"
CreateWindowEx - "ThunderFormDC"
CreateWindowEx - "ThunderFormDC"
CreateWindowEx - "ThunderFormDC" CreateWindowEx - "ThunderFormDC" CreateWindowEx - "ThunderFormDC" CreateWindowEx - "ThunderFormDC" CreateWindowEx - "ThunderFormDC" CreateWindowEx - "ThunderFormDC" CreateWindowEx - "ThunderFormDC"
CreateWindowEx - "ThunderFormDC"
CreateWindowEx - "ThunderFormDC"
 
CreateWindowEx - "ThunderFormDC"
CreateWindowEx - "ThunderFormDC"
 
-->