AknLayoutUtils::PenEnabled() and Backward compatibility

[ilsocio]

Reading this wiki page, http://wiki.forum.nokia.com/index.ph...ort_is_Enabled the PenEnabled() seems to be available on 3rd edition also.

But, I just noticed the AknLayoutUtils::PenEnabled() has been made public starting from 3rd FP1 and the aknutils.h distribuited in the 3rd MR SDK doesn't contain the PenEnabled().

In order to compile successfully I tried to modify the aknutils.h adding the missing methods:
static IMPORT_C TAknMainPaneState MainPaneState();
static IMPORT_C TBool PenEnabled();
But it doesn't links with the original aknutils.lib in 3rd MR

Is there any official workaround to compile?
Since the PenEnabled() has been published only from FP1, is it safe to use the method also for 3rd edition devices?

BR, Marco.

[ltomuta]

Adding some methods to the header file is easy. Adding them to the library, that would be a challenge.

[ilsocio]

Hi Lucian, thank you for your reply.
Of course, I was hoping that the methods were already in the library, like already happened in other cases.

Basically, I would like to mantain the same binary for both 3rd and 5th edition with slightly changes in the feedback.
How can I detect if the Pen Support is enabled, in 3rd Edition?
I've taken in consideration the Machine UID, but I prefeer to use a more general approach.

[olivier_randria]

Hi Marco,


I have not check but in v3 FP1, Penenabled() should return false, as there are no FP1-based devices with real pen features right?

So maybe the simplest would be implementing PenEnabled() in the header so that it returns false for 3rd MR sdk ?

Olivier

[ilsocio]

Hi Olivier, yes, it should return false in FP1.
The problem is only in 3rd without any FP, seems that this api has not been implemented in these devices, so, in order to mantain the backward compatibility with 3rd (NO FP) is not possibile to use this api.

If you implement it on your own, returning always false, the method will not be linked with the library, so, when you'll use the application on 5800 it will return false, because you're not using the method available in the library.

For mine application, I did a work-around in the code, using the EEventItemClicked of the listbox to detect if the Pen Support is enabled as soon as the user start to use the application.

But for a general case, it would be useful to know if the Pen Support is enabled before any user interaction.
In the meanwhile, I edited the wiki page adding FP1 to the description.

[olivier_randria]

I was thinking more about patching your 3rd MR SDK so that AknUtils has PenEnabled() defined and implemented in the header file. It should be ok as long as you work on the code alone and your application should link properly regardless of the SDK right ?

Olivier

[ltomuta]

I was thinking more about patching your 3rd MR SDK so that AknUtils has PenEnabled() defined and implemented in the header file. It should be ok as long as you work on the code alone and your application should link properly regardless of the SDK right ?

Olivier

This would work only if the intent is of building multiple versions of the application, each build with a diferent SDK.

However, what ilsocio wants is one built (with the 3.0 SDK) to be used on all 3rd to 5th Edition devices. That would require that the information whether the pen is enabled or not to come from a system library and not from own code, regardless of where that code is placed.

I am afraid that the solution around this is a litle bit complicated and it involves using two ECOM plugins, one providing an hardcoded PenEnabled() EFalse and the oher one the actual reading from the system library. Which ECOM plugin to use on a given phone can be determined at install time or at run time.

[gregory_sokoloff]

A slightly simpler version of Lucian's solution is to build a single DLL using the FP1 SDK. In the DLL, export a function for checking whether the pen is enabled. Implement that function in the DLL using AknLayoutUtils::PenEnabled(). Now, in your main program, dynamically load the DLL using RLibrary::Load(). If you are running on 3rd edition prior to FP1, the load will fail because the imported API for AknLayoutUtils::PenEnabled() is not available; in this case your code deduces that the pen is not enabled. On the other hand, if the DLL loads, then get the address of your exported function using RLibrary::Lookup(). Finally, call your function which in turn will call AknLayoutUtils::PenEnabled() to get the result you need.

It would be great if there were a simpler approach to binding dynamically to the Symbian APIs, but I don't know of one. For example, on Windows Mobile you can simply issue a LoadModule() to the core OS DLL, and then resolve the API using GetProcAddress() and the name of the API function. Something analogous would be a nice addition to Symbian.

[wizard_hu_]

It would be great if there were a simpler approach to binding dynamically to the Symbian APIs, but I don't know of one.

There is ECOM to, though it is invented for a different purpose, and it is not simpler.

For example, on Windows Mobile you can simply issue a LoadModule() to the core OS DLL, and then resolve the API using GetProcAddress() and the name of the API function. Something analogous would be a nice addition to Symbian.

Symbian exports-imports using ordinals, and not names. So a .dll does not contain the name of the exported methods. This reduces the size of both the .dll-s and the referring codes.
It may also matter that Windows API-s are mainly C, while Symbian C++ is C++.

[gregory_sokoloff]

There is ECOM to, though it is invented for a different purpose, and it is not simpler.Symbian exports-imports using ordinals, and not names. So a .dll does not contain the name of the exported methods. This reduces the size of both the .dll-s and the referring codes.
It may also matter that Windows API-s are mainly C, while Symbian C++ is C++.

Correct on both points, though neither is insurmountable. The ordinals are buried in the lib files, and a utility could extract them. The C++ API is implemented as a series of function calls with the first param for non-static member functions defined as the "this" pointer; thus, resolved member function addresses could be used to invoke the C++ API, but it would require care.

However, my main point wasn't to propose any particular mechanism for dynamic binding, just that providing some mechanism would be a boon. There are lots of alternatives.

[MiKeL]

Try to use this code:

TBool penEnabled = EFalse;

RLibrary avkonDll;
if ( avkonDll.Load( _L( "avkon.dll" ) ) == KErrNone )
{
#ifdef __WINS__
TLibraryFunction PenEnabled = avkonDll.Lookup( 3184 );
#else
TLibraryFunction PenEnabled = avkonDll.Lookup( 4251 );
#endif

if ( PenEnabled != NULL )
{
penEnabled = PenEnabled();
}

avkonDll.Close();
}


Maybe it will help :)

Tested on E61 and 5800XM

[gregory_sokoloff]

Hi MiKeL,

Just what I was looking for--nice job! My only question for you, is how did you figure out the ordinal number (4251) for the exported function? I'm guessing it's buried somewhere in the library files of the SDK.

Thanks.

[MiKeL]

It tooks me a few hours, but it looks like I succeeded.

Ordinals are part of DSO (lib) files, which work like a translator between function names and their ordinals.

For emulator, you can use dumpbin.exe to get ordinals from dll files.

For device, dso files are in ELF format. You can use readelf.exe to extract all information stored in them into text format. I have found this file in S60 2nd ed. FP2 SDK. It looks like this file is not in any S60 3rd SDK nor S60 5th SDK.

I hope this information will be helpful.

BR, MiKeL

[gregory_sokoloff]

Hi MiKeL,

There is the elfdump.exe tool in the newer SDKs that does the trick. I was able to use it to do just as you said. Good detective work!

BTW, your solution tests OK on the E90 and E60 as well.

Thanks.