NewLC - Tutorial - Comments

Re: Reading ZIP File in Symbian OS

zlatan24 — Fri, 09 May 2008 11:14:13 +0200

Use-damaged zip files,program supports Windows 98, Windows Me, Windows NT 4.0, Windows 2000, Windows XP, Windows XP SP2, Windows 2003 and Windows Vista,help users solve the zip recovery issues and always have control of their archived data,recovers information from damaged zip files and minimizes data loss during the zip recovery process,application is the fact that it employs several heuristic algorithms and methods to repair zip file or recover information from damaged zip files.

Re: LEAVE and TRAP

kavitha2085 — Fri, 09 May 2008 10:45:34 +0200

Great explanation with extreme clarity......... Thank you very much

Re: UIQ3 audio streaming with code

lori_c — Fri, 09 May 2008 09:31:58 +0200

hi,
I have got KErrPermissionDenied in MaoscBufferCopied when I play the auido, Why?

Re: FirstGps N95 error "unable to install" installind FirstGps

marciallus — Mon, 05 May 2008 09:35:18 +0200

When i wrate this tutorial it was just to present the symbian LBS API , It wasn't designed to be use as is in a real program.

For your sis problem, you can check this url : http://www.newlc.com/Why-the-fuck-won-t-my-SIS-file.html

--
MarCo

FirstGps N95 error "unable to install" installind FirstGps sis

christian le jalle — Wed, 30 Apr 2008 18:57:55 +0200

Hi ,

I have signed "fistGps " app with symbiansigned WEB,
after adding capabilities Location and ReadUserData , got a new sis file.
but installation of the signed sis file on N95 failed "unable to install"
work fine on Emulator
I have upgraded my N95firmwrar to the latest release. didn't fixed
Sounds it's coming from my Pkg file ?
I have created one with the following contents:

; Installation file for FirstGps example application
;
;Languages
&EN
;
; UID is the app's UID
;
#{"FirstGps"},(0xE1EF0018 ),2,0,0
;Supports Series 60 v 3.0
[0x101F7961], 0, 0, 0, {"Series60ProductID"}
%{"Forum Nokia Test EN"}
:"Forum Nokia"
;

; Four files to install
;
"$(EPOCROOT)\Epoc32\release\$(PLATFORM)\$(TARGET)\FirstGps.exe"-"!:\sys\bin\FirstGps.exe"
"$(EPOCROOT)\EPOC32\data\Z\resource\apps\FirstGps.rsc"-"!:\resource\apps\FirstGps.rsc"
"$(EPOCROOT)\EPOC32\data\Z\private\10003a3f\apps\FirstGps_reg.RSC"-"!:\private\10003a3f\import\apps\FirstGps_reg.rsc"
"$(EPOCROOT)\Epoc32\data\z\resource\apps\FirstGps.mif" -"!:\resource\apps\FirstGps.mif"

-
Run with no error .
I'm wondering what I'm doing wrong ???

I have also used the FirstGps classes in another application. worked fine on emulator
but crashed on the "live" N95 when calling the GPS function ....

Any help and suggestion will be appreciated
Christian

Re: Hardware and Software Debugging

rakeshjhaa — Sat, 26 Apr 2008 10:31:42 +0200

problem is make temp file other place exe dektop,D &c drive & other folder
please solution this problem

Re: Base64, Quoted Printable and UU Encoding and Decoding

eric — Fri, 25 Apr 2008 11:15:00 +0200

There are quite straightforward to use:

HBufC* escapedText=EscapeUtils::EscapeEncodeL(mySourceText,EscapeUtils::EEscapeNormal);
CleanupStack::PushL(escapedText);
...
// Do whatever you want with the escaped text
...
CleanupStack::PopAndDestroy(escapedText);

Re: > Writing a recognizer: The EZBoot recognizer source code

shravan_vip — Fri, 25 Apr 2008 07:33:18 +0200

Can u please help me in step by step procedure of " Autostarting an application"

My code is follows

#include
#include
#include "QuickStart.h"
//#include "C:\CWEx\ActiveObjs\ActiveDll\ActiveDll.h"

const TUid KUidemAMRec={0x0EBC2E40};

CMyRecognizer::CMyRecognizer()
:CApaDataRecognizerType(KUidemAMRec, CApaDataRecognizerType::ENormal)
{
iCountDataTypes = 1;
}

TUint CMyRecognizer::PreferredBufSize()
{
// no buffer recognition yet
return 0;
}

TDataType CMyRecognizer::SupportedDataTypeL(TInt /*aIndex*/) const
{
return TDataType();
}

void CMyRecognizer::DoRecognizeL(const TDesC& /*aName*/, const TDesC8&
/*aBuffer*/)
{
// this function is never called
}

void CMyRecognizer::StartThread()
{
TInt res = KErrNone;
//create a new thread for starting our application
RThread * startAppThread;
startAppThread = new RThread();

User::LeaveIfError( res = startAppThread->Create(
_L("MyThreadName"),
CMyRecognizer::StartAppThreadFunction,
KDefaultStackSize,
KMinHeapSize,
KMinHeapSize,
NULL,
EOwnerThread) );

startAppThread->SetPriority(EPriorityNormal/*EPriorityLess*/);
startAppThread->Resume();
startAppThread->Close();
}

TInt CMyRecognizer::StartAppThreadFunction(TAny* /*aParam*/)
{
/*
//wait 5 seconds...
RTimer timer; // The asynchronous timer and ...
TRequestStatus timerStatus; // ... its associated request status
timer.CreateLocal(); // Always created for this thread.
// get current time (microseconds since 0AD nominal Gregorian)
TTime time;
time.HomeTime();
// add ten seconds to the time
TTimeIntervalSeconds timeIntervalSeconds(50);
time += timeIntervalSeconds;
// issue and wait
timer.At(timerStatus,time);
User::WaitForRequest(timerStatus);
*/

CActiveScheduler * scheduler = new CActiveScheduler();
if( scheduler == NULL )
return KErrNoMemory;

CActiveScheduler::Install(scheduler);
// create a TRAP cleanup
CTrapCleanup * cleanup = CTrapCleanup::New();
TInt err;
if( cleanup == NULL )
{
err = KErrNoMemory;
}
else
{
TRAP( err, StartAppThreadFunctionL() );
}
delete cleanup;
delete CActiveScheduler::Current();
return err;
}//StartAppThreadFunction

void CMyRecognizer::StartAppThreadFunctionL()
{

/* CActiveDll* iActiveDll;
iActiveDll = CActiveDll::NewLC();
iActiveDll->ShowMessage();*/

TFileName fnAppPath = _L("E:\\system\\Apps\\AppUidViewer\\AppUidViewer.app");
RFs fsSession; //file server session
User::LeaveIfError(fsSession.Connect());
CleanupClosePushL(fsSession);
TFindFile findFile( fsSession );

User::LeaveIfError( findFile.FindByDir(fnAppPath, KNullDesC) );

CApaCommandLine* cmdLine = CApaCommandLine::NewLC();
cmdLine->SetLibraryNameL( findFile.File() );
cmdLine->SetCommandL( EApaCommandOpen );

RApaLsSession ls;
User::LeaveIfError(ls.Connect());
CleanupClosePushL(ls);

User::LeaveIfError( ls.StartApp(*cmdLine) );
CleanupStack::PopAndDestroy(3); // Destroy fsSession, ls and cmdLine
}//StartAppThreadFunctionL

EXPORT_C CApaDataRecognizerType* CreateRecognizer()
{
CApaDataRecognizerType* thing = new CMyRecognizer();
//start thread for our application
CMyRecognizer::StartThread();
return thing;
}

// DLL entry point
GLDEF_C TInt E32Dll(TDllReason /*aReason*/)
{
return KErrNone;
}

As you have said I have downloaded and installed the ezboot.sis into my N72 phone. Please explain me the remaining steps.

Iam getting canfused as to How to create .boot file and .mdl and their targets. Please explain me briefly. Whether it works on N72.

Re: About Symbian UIDs

tote — Tue, 22 Apr 2008 12:02:58 +0200

Please note that there is no UID statement in the MMP file of my DLL at all. I assume that based on the targettype the system assigns default UIDs (1 and 2) to it automagically, but not a UID3.

And gosh, how slowly N-Gage starts!!!

Re: About Symbian UIDs

alh — Tue, 22 Apr 2008 11:56:55 +0200

Thanks for the clarification, I didn't know it was possible to omit the uid3 when automatically loading your dlls.

So it sounded very confused/confusing when you called the automatic loading for static linking, when static linking is something different entirely and that doesn't need any uid at all. (I assume you still need uid1 and uid2 for your dll:s you autoload)

But I guess it makes sense... Its not strictly needed in this scenario, and doesn't provide any extra identification from the name of the file now when all dll:s have to be in /sys/bin

BTW, a good example of how excessive dll-usage can slow down the start of your application, take a look at the N-Gage first-access pack... it has 165(!) dlls that all are likely loaded on startup.

Re: About Symbian UIDs

tote — Tue, 22 Apr 2008 11:21:35 +0200

I think I'm not confused at all, however, admit that might have been not too accurate.

First of all, I confirm that TARGETTYPE LIB does exist and even more it is called static linkage. I was wrong and you were right, alh.

The other way, called dynamic linking, offers two ways for loading a DLL:

Importing a LIB file in your MMP file indicates that the DLL will always be loaded into the context of your executable (OR the executable in which your component is running), during executable start-up. All required information is known build-time that allows 1: the loader to load your DLL, 2: the code to use your DLL. Please note that I did not mention how demand-paging might affect DLL loading on purpose.
You don't have to import the LIB file in the MMP file, but you can locate and load it run-time as well (using RLibrary class). In practice, it means that as long as you don't load the DLL in question, it won't be loaded in the process context (unless another component has already loaded it), thus the process will load faster (don't have to load your DLL) and require less memory throughout the whole life-cycle.

Finally, please note that you don't have to specify a UID in your DLL's MMP file if you import its LIB file. We have tried it out and it worked well without any UIDs. I can't locate the section in SDK help, where it was described that UIDs are really necessary for polymorphic DLLs only. At that time (when I read it years ago) ECOM plug-ins did not exist at all, so I now presume that it applies to polymorphic DLLs + ECOM plug-ins.

Re: About Symbian UIDs

alh — Tue, 22 Apr 2008 10:29:45 +0200

I think you are confused.

If you build a dll, you specify TARGETTYPE dll and you you get a lib and dll pair.
You have to specify a UID.

You can then either specify the lib in the mmp or your exe, or use RLibrary.

BOTH ways are dynamic linking, in the first case though, it is done automatically for you when executing your exe, but it still is dynamic linking (using a dynamically loadable library).

Then there is also "static linking" but this is quite different, then you specify "TARGETTYPE lib" in your mmp file, and you end up with only a lib file, containing all code. You don't have to specify a UID.

Then you have to specify the lib file in the mmp of your exe, and it will be linked into your exe at compile time.

The main difference isn't that you can load and unload code, that is more into the "plugin" domain, the point is that the code is not statically included in the binary, but can be shared between several executables.

Re: About Symbian UIDs

tote — Tue, 22 Apr 2008 10:20:17 +0200

I meant mentioning the corresponding LIB file in the EXE's MMP file. That is static linkage. As opposed to dynamic linking, where you use RLibrary to locate and load (and unload) the DLL at any given time during the life-cycle.

Re: About Symbian UIDs

alh — Tue, 22 Apr 2008 09:37:27 +0200

how do you statically link to a dll?
static libraries of course do not need any uid, since they are no a file of their own on the phone, but part of the executable they are linked to.

Re: About Symbian UIDs

Genesis P — Tue, 22 Apr 2008 09:07:31 +0200

I'm not sure I would call this piece of information a "tutorial". It looks more like a short reference material, a short compilation made of reference material. I do not (and, of course, can not) object to this material being published here but then I do not feel like I've been actually 'taught' to do something after reading this. So they have all these varieties of UIDs, big deal. In practice, isn't it the opposite: you've been told to implement such and such exe (dll, device driver or whatever) you have a hell of headache with your implementation but it's difficult to imagine that you've chosen a wrong UID or have a lot of headache with UIDs at all. Teach me something applicable to my job, please. Oh, and actually the only might-be-interesting place - about SecureId - wasn't explained correctly as was noticed before. Oh, and shouldn't there have been very briefly explained UID ranges and very briefly outlined a process of acquiring an UID from Symbian (as opposed to using a development UID).- this is an important thing indeed. And who is srivivek anyway.