Re: WIN32LIB
Speaking as one of the "newbies" to both Euphoria and Windows programming, I
find myself agreeing with both David and John. One one hand, it would be nice to
have some more background and general principals to help put all this stuff
together, and on the other, it seems to me that the basic problem to be dealt
with is Windows itself, which is very large and extremely complex - I read
somewhere recently that there are over 17,000 "calls" in the API. There's just a
massive amount of detail to be digested, and it seems one's only hope is to
concentrate on the Windows stuff that appears to relate to a specific task, and
ask around when you "hit" a snag. Once one gets beyond the very basic, and
somewhat abstract, things like the event loop and messaging, things seem to very
rapidly become highly specific and profusely detailed. Which is why, I presume,
most of the books seem to run over 1200 pages, and none seem very complete.
I will be grateful for any efforts made to explain the workings of Windows, if
for no other reason than I often find that an explanation that's clear and
obvious to one person is completely meaningless to another. ("Intuitive" is one
of the most fallacious concepts in programming.) But I suspect that there's no
clear and straightforward way to explain a "system" that's so messy. One just
has to take the time to plow through lots of documentation and lots of examples.
A much less ambitious project I'm considering is recasting David's documentation
into a form that would be a little more accessible to my editor's online help
system. The editor seems to do fine at providing "context-sensitive" help using
RDS's help files but not so well with the win32lib document. Anyone have any
suggestions/requests on that score?
David Cuny wrote:
> Bernie wrote:
>
> > I think that you are going to run in to problems trying to explain
> > basic concepts of windows programming using win32lib.
> > win32lib whole idea and concept is to hide the details of windows
> > programming and make window programming easier.
>
> I agree.
>
> I think that, to a large extent, the best way to learn Win32Lib is to go
> through the examples, starting with EX01 and continuing. It attempts to
> introduce the concepts one at a time. EX01 creates an empty window; EX02
> creates a window with a button; EX03 attaches code to the window, and so on.
>
> On the other hand, it really helps to understand what's going on (and to
> grasp the code in the library) if you know something about how Windows
> works. I think there are (roughly) three different classes of users:
>
> 1. The 'newbie' who wants to write a Windows application, and doesn't care
> how Windows works. They need a tutorial on how to use the library; and that
> library has already been written. There's also a brief explanation of most
> of the functions buried in the middle of Win32Lib.doc.
>
> 2. The 'power' Win32Lib user, who wants to access some of the 'advanced'
> features in Win32Lib (flags, etc.). This requires that they work directly
> with the Win32 API. This isn't a difficult thing to do, but you have to
> understand how the Windows event loop works, how to hook things into
> Win32Lib, how to read C documentation, and how to convert that into Win32Lib
> terms. Not impossible, but it requires a fairly good knowledge of Windows
> programming.
>
> 3. The Win32Lib library writer, who wants to add to the functionality of
> Win32Lib. There's a bit of a writeup at the end of Win32Lib.doc, but it's
> way out of date.
>
> Since Win32Lib development is moving away from me, I should probably spend
> most of my documentation efforts of #3, explaining how Win32Lib works 'under
> the hood', to make it easier for coders to go in and add new features, track
> bugs, and so on.
>
> As for #1, I think the sad truth is that you just have to go in and play
> with the library, and decide what parts of it you need. There's no magical
> wand; you just have to find out what objects and routines are there, and
> play with them. Some things, like double buffering, sprites, and so on,
> could be written up much better than they are. But it's not really that hard
> to get Win32Lib up and running, even for a newbie.
>
> To get to #2 or #3, you need a some Windows specific knowledge. There are a
> lot of good tutorials and books out there, and I think they explain things
> better than I could. Just be sure to stay away from those that work with C++
> or MFC, and you'll be fine. Once you understand how Windows works, it's not
> that hard to figure out how to apply certain function flags, and so on.
>
> Win32Lib is fairly transparent; most of the routines you can just look at,
> consult the Win32.hlp file, and figure out what is going on. Internally, the
> code is well documented as to what it's doing, and why. Exending Win32Lib,
> once you know the basics of Windows coding, it not really that hard - just
> tedious!
>
> For example, take Judith's request to extend getPrinter to include paper
> orientation (landscape/portrait). If you take a look at the routine, you can
> see that it allocates a PRINTDLG structure, fills in some values, and calls
> the Win32 API function PrintDlg. Popping open Win32.hlp and looking up
> PrintDlg, you can see that none of the options include paper orientation.
> But the link to the DEVMODE structure shows that there is a dmOrientation
> field, which probably controls the paper orientation. From there, it's all
> grunt work. The real trick is figuring out how to incorporate the changes so
> that they work sensibly with Win32Lib, and not cause the application to
> eventually bloat and become a maze of function calls.
>
> -- David Cuny
|
Not Categorized, Please Help
|
|
