Re: MORE Lyle Blake Info......

From: L D Blake (not_at_any.adr)
Date: 08/17/04 

Date: Tue, 17 Aug 2004 05:03:34 -0400

On Tue, 17 Aug 2004 06:30:58 +0000 (UTC), erewhon@nowhere.com (J French)
wrote:

>>>>Why not use the standard windows Progress Bar control?
>>>
>>>Peversity - I just prefer my own stuff
>
>>[smile] Self defeating ... why duplicate windows functionality?
>
>Sometimes I find it makes sense
>- in this case it does not matter much

Frankly the only time it makes any real sense is when windows doesn't have a
control that will do what you want to do (eg. Graphing annual income)... then
you start from scratch.

There's seldom any benefit in re-inventing the wheel just because you can.

>I do quite a lot of DLLs for use with both Delphi and other languages,
>they are extremely useful - and I find Delphi a very good tool for
>writing them.

Hmmmm... I dunno... it's 6 of one half dozen of the other. As with most
things it's not so much the language as the technique that matters.

>>Now if we're talking units and appys... maybe I have more to offer.
>
>The lightweight controls will be part of the DLL
>- in one included Unit

Why not take all your best stuff, gather it into a DLL and produce your own
core functionality for Windows? There is cause to do this, so long as you
aren't simply wrapping windows native controls in other-named function calls.
i.e. there's no point producing a new Edit control... but there might be a
point in producing a DynaText control that can rotate and distort text.

>>You will want to make this mimic a windows control, then.

>That would be a later development, something I am quite interested in,
>but (fortunately) not the current objective

There are standards to the way these things are done. The most universal
controls and dialogs will be those that exactly mimic the way the existing
ones are created/used/destroyed by windows programs. It probably makes more
sense to get into the "standard" swing of things right from the start. Bad
habits are a lot harder to break than good ones.

>>A WM_Destroy message sent to *the window created in the appy* would ditch the
>>control and each child window gets it's own WM_Destroy message from that,
>>again, just like a windows control.
>
>Right - so WM_Destroy will zap the window

Just like it does for any other windows control.

>Yes, I've noticed that the class registration stays, I believe it is
>for the duration of the parent EXE
>- a good point about manually unregistering it, when the DLL is
>unloaded - the DLL might be unloaded without the App terminating

No... if you unload a well behaved DLL the class registrations are cleared out
in the DLL's exit code.

Your DLL proc should look something like this:

                Load the library...

                DllMain...
                        begin
                                register classes...
                                do message dispatcher...
                                unregister classes
                                free memory
                                etc.
                        End;

The DLL will unload when the Dllproc returns because there is no longer any
active code in it.

>>WM_Quit causes getmessage to return False, exiting the loop. You don't need
>>to flag it or mess with more difficult methods. Just do your cleanup after
>>the loop is broken.
>
>So basically when my routine has finished, send a WM_Quit to the
>window - makes sense

Not in a DLL... again the rules are similar but not quite the same.

If you are creating controls, you really should be using LoadLibrary and
FreeLibrary in your main program, and creating classes instead of a bunch of
exports in the DLL.

Again... the goal is to have it behave just like other windows controls.

>Actually I think I'm going to run into the same problem, as the
>Message Loop routine will need to be called from a number of places in
>a long sequential routine
>- just as one would call Application.ProcessMessages

In that case you would use a secondary dispatcher...

Looking at application.processmessages I see BLOAT... keep it simple...

                If peekmessage...
                        begin
                                translatemessage...
                                dispatchmessage..
                        end;

>That PeekMessage not responding may be tricky, because GetMessage
>appears to /wait/ until there is a message in the queue, and I most
>certainly don't want (need) that

Getmessage will sit there forever if no messages come along.

PeekMessage specifically doesn't respond to WM_Quit because it could lead to
uncontrolled program exits.

The secondary dispatcher should be used to A) Keep the UI active and B) break
out of whatever loop is running at the time. Beyond that it shouldn't do much
of anything at all.

>>Below, as an example is "Hello World" modified to use messaging to create and
>>destroy it's own windows. Note that in a DLL the "BEGIN" entry point would
>>actually be a DllProc and the entire MakeParentWindow mechanism would be in
>>the parent app.
>
><snip>
>
>Hmm - that is an interesting variation on the earlier version
>
>Of course the Parent App will almost certainly not be one of my own

None the less, you should still set it up to act like a standard windows
control...

>I can see a little problem with PeekMessage, it only works on a known
>HWND and I am pretty sure that GetMessage is 'blocking' if there are
>no messages to process

If hwnd is null (0) Peek message will fetch anything in the queue just like
GetMessage does...

>The DLL does not actually know anything about its parents HWND, the
>System.MainInstance is actually zero, although the GetMessage loop
>keeps the main App alive very nicely as it is thread based.

Controls in DLLs *never* know about their parents. It's all done through the
DLL's entry procedure... Again... a DLL is a separate instance from the
program loading it. You must have your own message dispatcher in the DLL
itself for the whole thing to work.

>I think that this might be a little more complicated than I first
>thought - a bit of digging inside Delphi is needed to see how they
>handle that problem.

You'd probably be better off digging into the SDK than Delphi.

Delphi is far more non-standard than people appear to realize.

>Yesterday I got stuck when I had multiple instances of the 'Progress
>Window' - but I've some ideas for handling that
>GWL_USERDATA looks the provided candidate....

If you're trying to prevent multiple instances you should use Mutex objects.

But that should be for the parent app, not the windows control. It really
doesn't make a lot of sense to have a control where you can only use one copy
at a time.

>Very interesting stuff this, thanks ...

No problem.

-----
Laura

Relevant Pages

  • Re: VB.NET 2008 not backward compatable?
    ... WPF has control templates and styles which offer ... a long hard slog with the API in VB6. ... Irony is you saying that Windows is COM centric and then blaming COM's bad ... VB can write a standard non-COM DLL. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: MORE Lyle Blake Info......
    ... >>A standard progress bar control, subclassed to put in the percentage... ... Painting your own may be fun, but it's really just duplicating what windows ... >possibly tell the DLL to shut down ...
    (comp.lang.pascal.delphi.misc)
  • Re: My own control
    ... After you compile your control as a library (dll), all you have to do is ... appear in the toolbox. ... > How hard would it be to make this new control available in the ToolBox? ... > happens to be a Windows Form application. ...
    (microsoft.public.dotnet.framework.windowsforms.controls)
  • Re: Problem with Custom Control in Building it when the same is used in a new windows project soluti
    ... See Windows Forms Tips and Tricks for an article on how to debug Windows ... I have created a custom control. ... it builds successfully but never overwrites the dll ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Re: older games dont work
    ... the support of my work have it and will burn a CD to me. ... and any other tips to make this game works will be great. ... Windows 95 including but not limited to: ... to map a pedal as a control ...
    (microsoft.public.windowsxp.games)