aygshell.h missing in WinCE6.0 SDK

[Peter K.]

I am porting my WinCE 5.0 image to "Windows Embedded CE 6.0 R2". For both
Windows CE images I have created SDKs which I am using with VS2005+SP1. I
have no problems to create MFC Smart Device applications in VS2005+SP1 with
my WinCE5.0 SDK. Unfortunately I get the following error if I use my WinCE6.0
SDK:

C:\Program Files\Microsoft Visual Studio 8\VC\ce\atlmfc\include\afxce.h:
fatal error C1083: Cannot open include file: 'aygshell.h': No such file or
directory

If I compare the files on my harddisk (c:\Program Files\Windows CE
Tools\...) of my WinCE6.0 SDK to the files of my WinCE5.0 SDK I can see that
the AYGSHELL.H is missing in the WinCE6.0 SDK folder but it is present in the
WinCE5.0 SDK folder. Why is AYGSHELL.H missing?

Interestingly: I have never included the AYGSHELL component in any of my
images (wether CE5.0 nor CE6.0).

Regards Peter

[Luca Calligaris]

You have to include AYGShell API in the OS design the SDK is based on to have
the relevant header
--
Luca Calligaris
www.eurotech.it

[Peter K.]

Hello,

that's the point. I have never used AYGSHELL in any of my WinCE images (and
I will not use this component in the future).

However if I create an SDK for my WinCE 5.0 image with PB5.0 the file
AYGSHELL.H is included even though AYGSHELL is NOT included in the WinCE5.0
image.

In my WinCE6.0 image AYGSHELL is also not included. If I create a SDK with
PB6.0 the AYGSHELL.H ist not present in the SDK. Unfortunately VS2005+SP1
(afxce.h) would like to use ist ...

Any ideas?

Regards Peter

[<ctacke/>]

Yes, CE 6.0 got it right. CE 5.0 included it by mistake. If aygshell is
not present, having the header doesn't do any good, as it won't link. If
for some crazy reason the lib is there too, then it will link but die when
you try to run.

--

Chris Tacke, eMVP
Join the Embedded Developer Community
http://community.opennetcf.com

"Peter K." <Pet...@discussions.microsoft.com> wrote in message
news:588FBC20-63B2-465A...@microsoft.com...

[Michel Verhagen [eMVP]]

I think everybody is missing the point:

"Unfortunately VS2005+SP1 (afxce.h) would like to use it"

So, what he's saying is that HE doesn't try to use aygshell.h, but the
standard afxce.h file is trying to include it. If afxce.h only
*includes* (by mistake) but does not *use* any of the functions in
aygshell.h, then the CE 5.0 mistake of falsely always including
aygshell.h in the SDK will cover up this 2nd mistake of always including
aygshell.h in afxce.h. CE 6.0 did get the SDK right by not including
aygshell.h in the SDK if it wasn't added as a component to the image,
but now the other mistake becomes visible.

Right?

Michel Verhagen, eMVP
Check out my blog: http://GuruCE.com/blog

GuruCE
http://GuruCE.com
Consultancy, training and development services.

[Marco Contenti]

Is this a SP1 "enhancement" of MFC 8.0?
I remember having a hard time trying to port a desktop MFC app to CE
5.0 with VS2005 (without SP1) about a year ago, but didn't notice this
detail. However I'm pretty sure that the configuration didn't include
aygshell, since it would be of no use on an industrial controller and,
most important, it's out of the core license set.

A few days ago I tried to create an MFC project to test a new 6.0 SDK,
but it complained about missing aygshell, trying to compile it just as
it came out of the wizard.
Then I tried to TEMPORARILY comment out that include statement and
found out that yes, it's actually used, I don't know what the hell for
- can someone from MS answer?

Well, MFC is not properly an OS component (actually it was removed
from 6.0), but rather a library that sits on the raw Win32 API.
So, you are not bound to use MFC 8.0 (which can also run on CE 5.0) to
be compatible with CE 6.0, except for the fact that this might be your
only choice. I don't know if there are any legal issues trying to link
the old MFC (available with PB 5.0, but also with EVC++) in a VS2005
app for CE 6.0.
Actually, that's exactly what I did (on CE 5.0) with my MFC app after
a few attempts with MFC 8.0. I had to tweak a bit include and lib
paths and change a few project options. The older MFC is not 100%
compatible with previous desktop versions, but porting was a lot easier.

Marco Contenti
PROJECT s.a.s. (MSWEP)
www.projectsas.it
marco.contenti@<see domain above>

Michel Verhagen [eMVP] ha scritto:

[Luca Calligaris]

Well, since you do not need aygshell at all you can try the following:
-remove aygshell from your image
-build the SDK

In your source code:

#define __AYGSHELL_H__ //prevent aygshell.h inclusion in afxce.h
#include <afxce.h>

--

Luca Calligaris
www.eurotech.it

"Peter K." <Pet...@discussions.microsoft.com> ha scritto nel messaggio
news:08079E27-FEA5-4801...@microsoft.com...
>I am stuck on this problem. If I add AYGSHELL to my image, although I do
>not
> need this component, I get this problem:
>
> If I click into any textbox the SIP will open. Because I have a device
> with
> keyboard I do not wan't to open the SIP automatically. I have deactivated
> the
> checkbox "Allow applications to change the input panel state" but this has
> no
> effect.
>
> Microsoft, how can I solve this problem?
>
> Regards Peter

[Marco Contenti]

Luca Calligaris ha scritto:

> Well, since you do not need aygshell at all you can try the following:
> -remove aygshell from your image
> -build the SDK
>
> In your source code:
>
> #define __AYGSHELL_H__ //prevent aygshell.h inclusion in afxce.h
> #include <afxce.h>
>

This won't work, afxce.h unconditionally includes aygshell.h and won't
compile without it.

Fortunately there is a solution: make aygshell.h and its dependent
shellsdk.h available to the compiler in the include path. This will
make the MFC header happy and your app will be compiled.
More important, the resulting .exe won't import from aygshell.dll if
you don't use it, so you can remove it from the image.

[Luca Calligaris]

Oops, you're right, me stupid!

--

Luca Calligaris
www.eurotech.it

"Marco Contenti" <marco.c...@nospam.com> ha scritto nel messaggio
news:uAEkAWBZ...@TK2MSFTNGP04.phx.gbl...