Glenn Linderman wrote:
Is it impractical to code the injected DLL so that it implements generic
methods for memory allocation, and API invocation, that can be scripted?
For example, Win32::API can invoke "any old Win32 API" if you teach it
how... could the injected Win32::GUI::Test DLL somehow be similarly
scriptable to call any old SendMessage if you teach it how (by writing
interface descriptions in the Perl client code, many of which would be
"pre-canned" for known, frequently used messages for frequently used
controls)?
Sounds reasonable. We have to think about it, maybe comming with some
prototypes. We should have two goals in mind:
1. User should be able to easily perform opearions on M$ controls (like
TreeView).
2. In the same time user should be able to deal with custom controls without the
need to modify xs files.
Pre-canning of messages for common controls would be a good thing. It would
require lots of work (maybe not that much actually - some analysis should be
required). But still a general mechanism should be available for custom
controls. I am not sure if using Win32::API is a best solution. As for me it is
slightly more error prone, since it is up to the user to check carefully what is
being passed as parameters. Also debugging seems to be slightly more difficult.
Using xs or even wrapper around Win32::API in pm file, will free the user from
making the same errors again and again.
[I remembered to delete you, Piotr, from the "Reply-All" list this time,
but I can't guarantee to always do that. While you prefer not to get
duplicate messages, many others prefer to get the duplicates, because
the direct one often comes much faster than the one through the list. So
my general practice is to simply Reply-All to mailing list messages.]
OK. I understand the reason now. Go ahead with your standard way. After all it
is not a big deal if I receive some duplicates.
--
Piotr Kaluski
"It is the commitment of the individuals to excellence,
their mastery of the tools of their crafts, and their
ability to work together that makes the product, not rules."
("Testing Computer Software" by Cem Kaner, Jack Falk, Hung Quoc Nguyen)
