Ezekiel Sanborndeasis <[EMAIL PROTECTED]> writes:
> I do not have a detailed list in front of me, but yes there are differences
> in the form of bug fixes. The one posted in the seeding area was beta and
> since then there has been some cleanup including a couple of tweaks to the
> new glue functions. The seeding area version was pretty darn stable it
> seems, but there is no reason not to move to the final version mentioned in
> Owen's post... and of course you should recompile anything done with the
> seeding version of SDK 4.0 Update 1 (especially if you used the static
> library glue functions).
>
> -Ezekiel
The following partial code (edited for clarity) does not compile for me
under the 4.0r1 SDK, but was fine under 4.0:
class GraphicsRecord {
private:
MemHandle recordh;
const struct _record {
UInt16 flags;
BitmapType bitmap;
}* data;
public:
GraphicsRecord(DmOpenRef db, UInt16 recnum) :
recordh(DmQueryRecord(db, recnum),
data(recordh? static_cast<_record*>(MemHandleLock(recordh)) : NULL) {}
const BitmapType* bitmap() const { return &(data->bitmap); }
// ... snip ...
};
The class implements a database record that contains some bitmap data
created using the standard BmpCreate function, and is stored in the
database by the application. Later on, the application fetches that
record, and displays the bitmap using WinDrawBitmap. All of the above is
done through standard Bitmap API calls.
The error I'm getting is that the bitmap field has an incomplete type,
which makes sense, because if ALLOW_ACCESS_TO_INTERNALS_OF_BITMAPS is
not defined, BitmapType is a simple struct declaration, and not a struct
definition. I can obviously get it to compile if I define
ALLOW_ACCESS_TO_INTERNALS_OF_BITMAPS.
I see four solutions:
1. #define ALLOW_ACCESS_TO_INTERNALS_OF_BITMAPS
This will set off tons of red flags in code reviews, because it looks
like I'm going to be accessing bitmap internals, even though I'm
not. In addition, I lose any protection I might have had against
inadvertently accessing bitmap internals.
2. Redefine my class to do something like
class GraphicsRecord {
private:
MemHandle recordh;
const struct _record {
UInt16 flags;
UInt8 bitmap_data[1];
}* data;
public:
GraphicsRecord(DmOpenRef db, UInt16 recnum) :
recordh(DmQueryRecord(db, recnum)),
data(recordh? static_cast<_record*>(MemHandleLock(recordh)) : NULL) {}
const BitmapType* bitmap() const {
return reinterpret_cast<const BitmapType*>(data->bitmap_data);
}
};
To me, this seems to obfuscate the code, but the more I think about
it, the more I think that it's the appropriate solution.
3. Treat it as an SDK bug and patch the SDK.
4. Wish the SDK was written in C++, which doesn't have to use ugly hacks
to protect private struct members :-) Ok, that's not really a
solution, just a whinge.
Actually, over the course of this post, I think I have a solution, but
I'll still post for others' information. Any comments are still welcome.
--
Dave Carrigan ([EMAIL PROTECTED]) | Yow! Why am I in this ROOM in
UNIX-Apache-Perl-Linux-Firewalls-LDAP-C-DNS | DOWNTOWN PHILADELPHIA?
Seattle, WA, USA |
http://www.rudedog.org/ |
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
