Creme/MI2.5/loadLibrary problem

[Former Member]

We have two functionalities in our MAM application: texting and signature capturing. These work flawlessy on our PDA running Windows Mobile 2003/Creme 3.25/MI 2.5 SP15. When we deploy the application on the PDA running Windows Mobile 2003 SE/Creme 3.27, these functionalities wont work. Both cases the problem seems to be loading DLL files.

The details:

1. Signature capturing

The capturing is done in an AWT frame. When I call frame.show() or frame.setVisible(true), this error occurs:

<b>** gfw_font.c can't find T2K.dll</b>

java.lang.ExceptionInInitializerError

at sun.security.action.GetPropertyAction.run()

at sun.porting.windowsystem.WindowSystem.getFont()

at sun.awt.otk.ObjectToolkit.getFontPeer()

at java.awt.Font.initializeFont()

at java.awt.Font.<init>()

at

at

at sun.awt.otk.WindowModel.setDefaultView()

at sun.awt.touchable.TouchableToolkit.mapComponent()

at sun.awt.touchable.TouchableToolkit.createFrame()

at java.awt.Frame.addNotify()

at java.awt.Window.show()

at java.awt.Component.show()

at java.awt.Component.setVisible()

at java.awt.Container.setVisible()

at com.wscgmbh.mbs.sign.Signature.<init>()

at com.wscgmbh.mbs.sign.Main$1.run()

The t2k.dll is on the filesystem in the \windows\creme\lib directory. After copying the file to the \windows directory, the problem still remains.

2. Sending SMS

We use 3rd party classes for sending a SMS. It uses a DLL. The error I receive (custom error) tells me the library isnt loaded.

Does anyone have a clue why the application works on Windows Mobile 2003/Creme 3.25 but not on Windows Mobile 2003 SE/Creme 3.27 ??

[Former Member · Accepted solution]

Hi,

have you tried out different combinations?

Use the Creme 3.25 on the SE device and vice versa. So you can get a rough impression if may the DLL does not work on the SE device or if the Creme Version has a problem using this DLL.

Have you tried it out more than once, could be possible that the DLL is corrupt?

Rgds Tom

[Former Member · Accepted solution]

It looks like two different errors. The capturing part works fine when we use Creme 3.25 on both Mobile 2003 and Mobile 2003 SE. Got the feeling this is a MI/Creme 3.27 conflict. Problem is we dont control the loading of the t2k.dll, I think Creme does.

The SMS part works fine on Mobile 2003 with both Creme versions, but it wont work on Mobile 2003 SE.

[Former Member · Accepted solution]

HI,

I heard that CrEme 3.27 is still not released officially. So download the current version (I guess 3.26) of creme (sap note 772334)

As well check note: 897289

---

ATTENTION:

For CrEme versions 3.25 and 3.26 there is an acknowledged by NSICOM bug as plug-in registration link contains wrong dll path for those versions. Copy/Paste both "Register/Unregister Plug-In" files from \Windows\CrEme\Demos to your desktop with the help of ActiveSync, open both dlls and change the existing line with the following

\windows\regsvrce.exe \windows\creme\bin\CremePie.dll. It is possible to deploy updated versions of these files to avoid manual changes on each device.

7. Restart Mobile Engine.

---

Rgds THomas

[Former Member]

Mike,

To generate a DLL for PPC 2003, acessing by JNI (JVM is CrEme), is necessary the interfaces (jni.h, etc..) of CrEmE? Or can be generate with the interfaces of JDK 1.1.8?

Thanks

[Former Member]

I dont know Fabricio, i have never created a DLL for JNI/JAVA.

[Former Member]

Problem solved: apparantly there is a Windows Mobile 2003 SE bug involving virtual memory management and loadlibrary(). Solved this issue by loading the libraries when tomcat is started.

[Former Member]

Hi,

To use a DLL in PPC 2003, has to put the DLL in WINDOWS diretory with the others DLL or in other directory?

Thanks.

[Former Member]

If you are using Creme, libraries need to be in the \windows or \windows\creme\bin directory.

[Former Member]

Hi Mike,

I change to windowscreme in directory and continue the problem. The DLL is load, but the function is not... My header is:

Java Code

package br.com.fiscalizacao.arcpad;

public class nativetest{

	static {
		System.loadLibrary("nativetest");
	}
	
	public native String sayHello(String x);
					     
	public native String SendScript(String x);
	
	public static void main(String[] argv)
	{
		
		nativetest nt = new nativetest();
		
		//Método 1
		String x = nt.sayHello("Access to DLL do with success.");		
		System.out.println(x);
	}
}

Header Code

JNIEXPORT jstring JNICALL _Java_br_com_fiscalizacao_arcpad_nativetest_sayHello
  (JNIEnv *, jobject, jstring);

Is there anything wrong in this code?

Thanks.

[Former Member]

Hi Fabricio,

I cant reply on your last answer because there isnt a reply button. Im not very into creating DLL files, this was my first JNI problem.

The only thing I can think about is: did you use a compile to create the DLL for the PPC device or is it the same DLL as you use for your win32 device?

Mike

[Former Member]

Hi Mike,

It's my first JNI problem with PPC 2003 too...

I'm using embedded visual C++ 4.0 to create DLL for PPC 2003 and i used Dev-C++ to DLL desktop version (Win32)...

Have you ever get to work a DLL with JNI in PPC 2003?

[Former Member]

Hi Fabricio,

Well.. kind of.. but we did not build the dll and its functions ourselves. We used a third-party library, already wrapped in a java class.

[Former Member]

Mike,

But... Do you think that Java Code is rigth? Do you think that the problem is with the DLL generation?

Thanks.

[Former Member]

Hi Fabricio,

The java code looks okay to me. What happens when the nt.sayHello() is executed?

[Former Member]

Mike,

The error is:

java.lang.UnsatisfiedLinkError: sayHello

...

Do you have any idea?

Thanks

[Former Member]

For all I know, that error means Java cant load the DLL. Do you get this error during the LoadLibrary()?

[Former Member]

No...This error occours when the method is call...

The error with DLL loading is :

java.lang.UnsatisfiedLinkError: no <name of DLL> in java.library.path

...

I think that the problem is in DLL generation, but i couldn't find this generation error, because the DLL is generate with success...