On Thursday 07 August 2008, you wrote:
> Davy Preuveneers wrote:
> > Here are some screenshots that show the menu implementation:
> > http://www.cs.kuleuven.ac.be/~davy/phoneme/other.htm
> > One of the questions that might pop up is:
> > Would it be possible to have the same visual result as for PPC03?
> I think it's fine the way you have it. An extra "Application" menu
> doesn't seem that crucial. Technically, I think it's more correct,
> since in the future you might see that WM5.0 (or above) adds something
> as the "system" menu items that would be on every menu (with
> edit/send/open type menu items or other system level menu items). So,
> having a place for just Application menu items seems right.
Currently this is not the case. None of the WM versions I have seen, modifies
an application defined menu. This means for pMEA that the content of the menu
is only defined by what is in the rc file (the dummy menu entries) and if/how
it is replaced with the AWT menu. If there would be a "System" menu, it would
have to be added by pMEA itself.
> > The answer: Maybe. Instead of adding the AWT menu directly as a submenu
> > with the caption "Application", I would have to traverse the AWT menu one
> > by one for all its submenus and menuitems, and recreate those to add them
> > with the original caption to the base "Menu" menu. This is rather tricky,
> > and I haven't been succesful to implement this. The only WinCE methods
> > that seem to work are DeleteMenu and InsertMenu. Although many other
> > win32 methods exist to handle menus (SetMenu, InsertMenuItem, ModifyMenu,
> > ...), they are not supported on WinCE I am afraid.
I will leave it like it is for the time being. If I know how, I will try to
properly merge an AWT menu with the dummy one on WinCE so that it resembles
the menu on WM2003.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Davy Preuveneers wrote:
>>> The answer: Maybe. Instead of adding the AWT menu directly as a submenu
>>> with the caption "Application", I would have to traverse the AWT menu one
>>> by one for all its submenus and menuitems, and recreate those to add them
>>> with the original caption to the base "Menu" menu. This is rather tricky,
>>> and I haven't been succesful to implement this. The only WinCE methods
>>> that seem to work are DeleteMenu and InsertMenu. Although many other
>>> win32 methods exist to handle menus (SetMenu, InsertMenuItem, ModifyMenu,
>>> ...), they are not supported on WinCE I am afraid.
> I will leave it like it is for the time being. If I know how, I will try to
> properly merge an AWT menu with the dummy one on WinCE so that it resembles
> the menu on WM2003.
Sounds good. Thanks for your help, Davy!
The PhoneME Advanced has support Location API?
On Saturday 09 August 2008 16:11:03 AcÃ¡ssio Novais Queiroz wrote:
> Hi All,
> The PhoneME Advanced has support Location API?
Are you talking about PhoneME Advanced on Windows Mobile or about PhoneME
Advanced in general? Are you developing midlets, or regular Java applications
on top of CDC/Foundation/Personal Profile?
Presuming you are developing midlets for Windows Mobile, I can tell you that
currently the phoneME subversion tree does not contain any sources for a JSR
179 implementation. However, the sources zip of the recently released PhoneME
Feature MR3 does:
I have the impression that these sources will only work on Windows x86 systems
as the jsr uses Lime within the javacall porting layer. Also, you cannot
compile the pMEF MR3 sources for PhoneME Advanced because many configuration
and build files are missing for a CDC based implementation (PhoneME Feature
is CLDC based). Moreover, depending on the platform you target (windows/x86,
wince/arm, linux/x86, linux/arm, ...), you need support for a real location
provider (e.g. a bluetooth or built-in GPS module).
That said, I was able to quickly hack together a NMEA log parser and use that
as a dummy location provider for a pMEF Windows Mobile build and that seemed
to work. Hooking it up to a real GPS of course would be much better, but is
not so trivial as it is pretty much device and OS specific!
For pMEA you may want to have a look at OpenLAPI (http://www.openlapi.com/),
add kxml2-min-2.3.0.jar, openlapi-0.9.11.jar and openlapi-jsr179-0.9.11.jar
to the classpath and test your midlet. In order to import classes from the
javax.* package from openlapi-jsr179-0.9.11.jar, you may need to modify
MIDPPermittedClasses.txt by adding the following lines:
I have not tested this, so YMMV.
PS: You may want to start a new thread if you have more questions regarding
Location API/JSr179 as this thread deals with another topic (Personal
profile, java.awt.Frame issues).
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2015, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.