Hi,
part of what I have written comes from the source code that has been
"embedded" in the application's source code. (I have no idea where they
took if from. It is quite possible that these definitions come from
original MS include files, as the "original" application was meant to be
compiled with the MS compiler. No idea why they decided to include some
definitions - possible because different version of MS tools come with
different sets of include files and the application source code always
needs some of them, which are not always present on the user's system?).
Some notes about missing include files in CeGCC (as compared to the MS
tools, whatever this means - possibly " MS version specific") come from
private mail exchanges with people who were developing the "original"
application with MS tools (i.e. not with CeGCC). They could then tell me
that a particular include file, which they "#include <some_file.h>" in the
source code, is needed for a specific function declaration, for example.
That is also basically how I've learned that some_magic_file.h should
include another_magic_file.h, for example (I believe they've check it on
their systems). I don't claim that these notes are 100% correct, but at
least it makes sense what I've been told.
Note also, the "versions" of files, that I have "prepared", are really
"dumb" versions of these files. I tried to "mimic" what I've been told
about them - they include only these definitions that I needed now (well,
maybe in future I will "expand" them - if I find I need more).
Anyhow, I didn't blindly believe what they were telling me!
I've always tried to verify their stories!
If you'd like to get a link to a "reliable document" for everything I have
written, let me know. However, I will need some days then ...
I need to search for the "documents" and "code examples", in which I've
found/confirmed these defines (in the meantime, I've forgotten
everything about it ...)
> The IMINFO definition that you send looks different from the one I find
> on MSDN. (Enter "IMINFO ce" as search string.) Where did you get this
> info from?
This particular question I can answer immediately at no cost.
This is one of the definitions that I have found in the "original" source
code of my application. I could verify it using, for example:
http://www.microsoft.com/mspress/books/sampchap/5461b.aspx
http://www.zhangzhou.net/download/Wince/DISK2/POCKTSDK/Program%20Files/INCLUDE/sip.h
(BTW. Note that the last link seems to be a fairly complete "sip.h"
include file. I have no idea, however, whether it is really correct.)
> The KeyStatePrevDownFlag which you say should be in keybd.h is
> documented on an MSDN page for PostKeybdMessage which says you need to
> include winuser.h .
This particular question I can also answer immediately at no cost, at
least in the part that concerns the "KeyStatePrevDownFlag".
Again, this is one of the definitions that I have found in the "original"
source code of my application. I could verify it using, for example:
http://msdn2.microsoft.com/en-us/library/aa930591.aspx
http://msdn2.microsoft.com/en-us/library/aa454420.aspx
I'm sorry, but I cannot find "PostKeybdMessage" in my files now.
I think I've again lost a mail or something.
Could you, please, remind me what was the story with the "PostKeybdMessage"?
> > The following functions are missing in the "aygshell.h" and
> > in the "libaygshell.a", please implement them:
>
> MSDN says they exist in WinCE 4.0 and higher. So this raises the
> question again which version of CE we support. If I create a
> distribution that has support for these functions, then it won't work
> with CE 3.x devices.
Note, most of today's devices are WinCE 5 and 6 based.
A lot of existing source code uses these functions.
> A workaround for that might be to include the right tools for creating
> your own library files even in our binary distributions. Pedro, your
> opinion ?
Not really a good idea.
I would like to be able to generate binaries which could be used on many
systems, not only on my own (and sometimes "excluding" my own).
Hence, I need FULL libraries, and the compile-time preprocessor options
(encoded by me in my source code, of course) which switch a particular
behavior on/off.
> > Finally, there seems to be a problem with the "PathCombine"
> > function (declared in "shlwapi.h"). I believe this is the
>
> Is this the right patch ?
I cannot really test your patch on my device, sorry.
Although it is WinCE 5.0 based, it lacks this function.
The "SHLoadImage*" functions are missing, too, of course.
So, it is NOT just the WinCE kernel version that matters.
I believe the problem is that there is the "core WinCE version" and
on top of it, there are the "PocketPC" and the "SmartPhone".
With the WinCE 6, you have "Core 6", "Professional", "Classic" and
"Standard" versions (each of them implements a partially different set of
functions) - see my FAQ, I've tried to describe it in there.
Hope it helps,
Best regards,
Jacek.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
