Sorry, this was incorrect, I commented out the troublesome line of code,
went to lunch, *then* touched window.h and everything was fine (on Palm OS
3.5).... so in fact I did not fix it at all <sigh>

However, I have now fixed it by not using the "PalmOS_Headers_Strict_Debug"
prefix file that was in my project by default. This seems to be like a
Precompiled header file in VC++ but I can't figure out how to rebuild it
with ALLOW_ACCESS_TO_INTERNALS_OF_WINDOWS defined....

-----Original Message-----
From: Idries Hamadi 
Sent: 27 May 2002 14:30
To: Idries Hamadi; 'Palm Developer Forum'
Subject: RE: Access screen with Palm OS 4.0


I touched the windows.h file and everything got fixed...

-----Original Message-----
From: Idries Hamadi 
Sent: 27 May 2002 12:54
To: 'Palm Developer Forum'
Subject: RE: Access screen with Palm OS 4.0


Ok, the Beamer.c app compiles without a problem and it can access this
member without any special screwing around (it doesn't even #define
ALLOW_ACCESS_TO_INTERNALS_OF_WINDOWS).

I'm starting to think that this is a problem with my project setup. I've
tried "Remove Object Code" from the Project menu (I think that this is the
equivilent of "Clean" or "Rebuild all" in MS Visual C++), this doesn't help.
The only real difference that I can see between my project and Beamer is
that I am using C++, could this be somthing to do with it?

Cheers,
        Idries

-----Original Message-----
From: John Marshall [mailto:[EMAIL PROTECTED]]
Sent: 27 May 2002 12:26
To: Palm Developer Forum
Subject: Re: Access screen with Palm OS 4.0


On Mon, May 27, 2002 at 11:41:08AM +0100, Idries Hamadi wrote:
> Error   : illegal use of incomplete struct/union/class 'struct WindowType'
> GamePage.cpp line 193     bufferPtr = (u1*)fScreenBuffer->displayAddrV20;
> 
> This seems to be because the WinHandle struct is opaque in the headers for
> the Palm OS 4.0 SDK.

Right.  This error message is the compiler's way of telling you that.
(In fact, this error message is what "opaque" means from the compiler's
point of view :-).)

> Looking in the OS 4.0 readme and other docs it seems
> that this is deliberate to force people to move to using the access
> functions (in this case WinGetBitmap and BmpGetBits).

Correct.  If your code is only for use on old devices, you can still
write code like this by defining ALLOW_ACCESS_TO_<foo> macros, but
the SDK wants make sure you are aware of the issues involved (and it
certainly sounds like you are) and that you're making a *conscious*
decision to use these non-portable constructs anyway.

> Now, looking at the
> WinHandle typedef I find that defining
ALLOW_ACCESS_TO_INTERNALS_OF_WINDOWS
> will make the struct non-opaque again. So, I define this at the top of my
> cpp file and still get the same error.

Defining an appropriate subset of the specific ALLOW_ACCESS_TO_<foo>
before you #include any Palm OS headers is certainly the intended way
to make the specific ones you want non-opaque.  No matter whether the
default value of the general DO_NOT_ALLOW_ACCESS_TO_INTERNALS_OF_STRUCTS
is "allowed" (undefined, as in the 4.0 SDK) or "not allowed" (set, as in
Update 1), defining one of the specific ALLOW_* ones overrides it.

In particular (as I think you're aware, but for the benefit of the
studio audience :-)), there isn't any need to go around modifying SDK
headers like BuildDefaults.h, either in the 4.0 SDK or 4.0 Update 1.
Sure, doing so will probably get the job done, but it's a brute-force
non-selective way to do it that will adversely affect your other
projects that don't need the deprecated access to structs and would
benefit from the extra checking.

> This is the first time that I've used Code Warrior, is
> there some cleaning step that I have to perform to re-compile the header? 

Perhaps there's something weird with pre-compiled headers going on, and
you have to rebuild them.  Perhaps you're #including <PalmOS.h> from a
prefix file, before your definition of ALLOW_ACCESS_TO_<foo> gets a
chance to have an effect.  But I'm just grasping at straws :-), you
should wait for someone more knowledgeable about CW to answer this part.

Ben, I thought there was something about this on palmoswerks, but
couldn't find it.  The closest seemed to be

        http://www.palmoswerks.com/stories/storyReader$12

which talks about rebuilding precompiled headers.

    John

-- 
For information on using the Palm Developer Forums, or to unsubscribe,
please see http://www.palmos.com/dev/support/forums/

-- 
For information on using the Palm Developer Forums, or to unsubscribe, please see 
http://www.palmos.com/dev/support/forums/

Reply via email to