Jason,
I know that we exchanged emails about this in the past, but unless you
have downloaded and looked at the latest CVS source you won't have seen
what I did for notify icons.
It's not very pretty, as I wanted to put it in with minimum changes to
the existing code - it really needs a complete refactoring - but my
technique was (approximately) as follows:
(1) remember that most features are not really OS dependent, but
dependent on DLL versions. DLL versions are mostly OS dependent, but
sometimes an OS can have a DLL upgrade. For example with NotifyIcons
the dependency is on the version of shell32.dll (IIRC), with balloon tip
being supported on Version 5 of the DLL and later - it happens that this
means they are supported in W2k and later.
(2) I used Win32::GetFileVersion() to get the DLL version information.
There are better ways to do this, and I will eventually write the
correct code in XS to do this reliably for all DLLs.
(3) I then fill the correct structures to pass, and enable/disable
method calls based on the DLL version at run-time. In this case the
structure simply has different sizes and additional members allowed for
the different DLL versions, bu the same technique can be applied even
where the structures change completely.
Regards,
Rob.
Jason P wrote:
Spot on to how I was thinking of doing it Glenn :)
Of course performance is an issue! Wish it was less of one, but hey.
So any other objects people can think of off the top of their head??
Jason P
Glenn Linderman wrote:
Sorry, that was a context free response. Perhaps I should have known
and remembered that you were working with Rob on that NotifyIcon
stuff. I really haven't seen a lot of
OS-version-independent-but-supports-latest-features code out there;
most code seems to set a threshold of OS support, and sticks with the
available features rather than choosing dynamically. And when some
new feature becomes really desirable, they abandon the old version of
the code, possibly still supporting it for use on old OS versions, and
come up with a new version of code compiled with a newer OS baseline,
where the desirable feature exists. This fits the MS model well...
the new features (and bug fixes) in the new version of such
applications help drag people forward onto newer versions of the OS.
And so MS's philosophy gets reinforced by every such application, just
as they planned.
Yes, most of the structures have common prefixes, but in some cases
the internal structures changed too. For truly variant structures, it
would seem necessary to have a separate pack-unpack method for each
structure version that one must support (per API, there are no more of
these than versions of Windows, but for many APIs there are fewer than
versions of Windows). The pack-unpack method should probably convert
to a common format hash, possibly with some flags set to indicate what
capabilities are [not] available on this version of the OS. Then the
GUI functionality could manipulate those hashes to set/unset options,
and when it comes time to call the Windows APIs, the appropriate
structure packer would be called, and then the API, followed by the
appropriate structure unpacker. Then results would be returned based
on the result hash. For prefix structures, a single but version
sensitive structure pack-unpack function pair could probably be
reasonably maintained.
This technique may not produce the highest performance, but seems
quite flexible, and for UI work, the performance generally isn't all
that critical. Of course, on old machines, everything is slow, once
you've used a new machine! I have seen machines on which Perl GUI
programs are just simply too slow for usable functionality.
On approximately 1/25/2006 2:23 PM, came the following characters from
the keyboard of Plum, Jason:
Yes Glenn, you hit the nail on the head. This is the "fun" bit Rob and I
ran into when adding the balloon tips to the NotifyIcon. I've been
working on the specifics on how to *fidget* the methodology
appropriately into the code for Win32-GUI, and have about half of it
done. Not that does me any good at the moment as I have to use Win32-API
to pack/unpack the differential structures....XS is prettier.
I was simply looking for other examples where this occurs. NotifyIcon
thankfully actually has a structure that simply had data fields added to
the end, and only the end, thus leaving one capable of simply setting
the SizeOf to the previous versions size! Not every object has been so
nicely ported between windows versions.
Win32::GetOSVersion doesn't solve all the problems btw, but thanks for
note on it for others that may not have seen the function before :)
[started with that].
Jason P
-----Original Message-----
From: Glenn Linderman [mailto:[EMAIL PROTECTED] Sent: Wednesday,
January 25, 2006 2:55 PM
To: Plum, Jason
Cc: perl-win32-gui-users@lists.sourceforge.net
Subject: Re: [perl-win32-gui-users] OS Version-Limited Features
Seems like Rob May recently added Balloon help to notify icons, as a
conditionally available feature based on OS version. I haven't yet
had a chance to look at his code changes.
Everything is possible, of course, but it seems that the MS way of doing
multiple versions is to define different length structures, whose length
is initialized before passing to the API, and the "easy" method of doing
that is recompiling with newer header files, rather than dynamically
determining which version to use based on the OS version. So, MS
doesn't make it easy to build a module that customizes itself to the
capabilities of the OS... but then again, their design center is to make
things easy to encourage people to upgrade the OS.... want this feature?
Upgrade the OS. And if an App wants to use a feature not in Win95,
and does so using the MS way, then it locks itself out of the Win95
market... want this app? Upgrade the OS... etc. Upgrade, upgrade,
upgrade, more $ for MS :)
But, it is possible, you just have to work harder at it.
On approximately 1/25/2006 10:26 AM, came the following characters
from the keyboard of Plum, Jason:
Hey Everyone,
I've been working on a way to determine which features of the user
interface are capable of being used based on the version of the OS the
script is running on. I know that currently Win32-GUI limits itself to
the feature set available to Win9x in order to maintain compatibility.
My question to the members of the list is what feature(s) do you
know are not currently implemented/active in Win32-GUI due to this
circumstance.
I've been trying to work out a way for the module to figure the
capabilities and availability of some of the extended features of
objects such as NotifyIcons. To do this it needs to know which version
of the structures to use based on the OS and DLL versions. I'm
simply looking for other examples.
Jason P.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log
files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Perl-Win32-GUI-Users mailing list
Perl-Win32-GUI-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
http://perl-win32-gui.sourceforge.net/
