Display the image in the Symbian exe program

Displaying graphics in Symbian EXE programs.
Display the image in the Symbian exe program
 
Generally, exe programs are used to implement servers (exedll, epocexe target type) or

Simple console programs. This may lead to believe that graphical features are not available

For EXE programs. This is not the case, and even though it might take some extra work

Set up an appropriate environment, this is quite straight forward to achieve, as

Following snippet will have strate. This way, we can make use of graphics without having

Resort on a full blown application.
Usually, the EXE program (exedll, epocexe type) is used to implement the server side or a simple console program. So make everyone

It is considered that graphical features are unnecessary for EXE programs. In fact, this is not the case. Even it needs to do some extra work to set

The appropriate environment is very convenient, as shown in the following example.

Our aim is to simply emulate the minimum set up provided by the framework when

Application (. APP) is loaded. Being a DLL, an application needs a process to attach.

This is provided by apprun.exe, which besides catering its own process and thread, CILS

Eikdll: runappinsidethread (), which-among other things-creates a cone Environment

(Ccoeenv)

Our goal is to simulate the minimum configuration provided by the framework when an application (. APP) is loaded. As a DLL

This is what apprun.exe is used to implement. Apprun.exe is not only used for its own processes and threads

High resource, it also calls eikdll: runappinsidethread () to create a cone environment (ccoeenv ).

When a cone environment is created, it sets up a cleanup stack, active schedsets

(Ccoeschedsions), and sessions to the file and window server (which can be later retrived

Calling ccoeenv: fssession () and ccoeenv: wssession (). Then it creates a screen, a window

Group and a graphic context, among other things. Later, after the newapplication () Factory

Function is called by the Framework, the ccoeappui (from where the application's Appui

Derives) creates the Control Stack, view Manager, etc. And the ccoecontrol derived class

Will create a window (rwindow) to provide a basic view. As you can see, this snippet

Provides all this basic functionality at once, without extra bloat such as a control stack,

Etc. Which aren't needed in this simple case. I Aven't encoded comments, as most of

Code speaks by itself.

After the cone environment is set up, set the ccoesched for clearing the stack activity object scheduler (ccoesched), create a session with the file, and the session with the window server (later

It is used when ccoeenv: fssession () and ccoeenv: wssession () are called ). Create a screen, window group, and graph.

Below. Then, after the factory function newapplication () is called by the framework, ccoeappui (the Appui driver from the application)

Create a Control Stack and view Manager. The inheritance class of ccoecontrol creates a window (rwindow) to provide the basic view. Just like you

As you can see, this program fragment only provides the basic functions and does not have any redundant things like the Control Stack.

Not required in a single example program. We didn't comment it out, because the Code itself has already explained the problem.

Local_c void exemainl ()
{
Rwssession ws;
User: leaveiferror (WS. Connect ());
Cleanupclosepushl (WS );

Cwsscreendevice * screen = new (eleave) cwsscreendevice (WS );
Cleanupstack: pushl (screen );
Screen-> construct ();

Rwindowgroup WG (WS );
User: leaveiferror (WG. Construct (reinterpret_cast <tuint32> (& WG), efalse ));
Cleanupclosepushl (WG );

WG. setordinalposition (10, ecoewinpriorityalwaysatfront );

Cwindowgc * GC;
User: leaveiferror (screen-> createcontext (GC ));
Cleanupstack: pushl (GC );

Rwindow window (WS );
User: leaveiferror (window. Construct (WG, reinterpret_cast <tuint32> (& WG) + 1 ));
Cleanupclosepushl (window );
Window. setbackgroundcolor (trgb (0x90, 0x90, 0x90 ));
Window. Activate ();
Window. setextent (tpoint (0, 0), tsize (screenwidth, screenheight ));
Window. setvisible (etrue );

GC-> activate (window );
Trect rect = trect (window. Size ());
Window. invalidate (rect );
Window. beginredraw (rect );

GC-> setbrushstyle (cgraphicscontext: esolidbrush );
GC-> clear ();

Tint64 seed = User: tickcount ();
Trgb color [] = {krgbred, krgbgreen, krgbblue, krgbyellow, krgbcyan };

For (tuint I = 0; I <10000; ++ I)
{
Tint x = Math: rand (SEED) % screenwidth;
Tint y = Math: rand (SEED) % screenheight;
Tint W = Math: rand (SEED) % 50;
Tint H = Math: rand (SEED) % 25;

Trect rect (tpoint (x, y), tsize (W, h ));
GC-> setbrushcolor (color [I % sizeof color]);
GC-> drawrect (rect );
}

Window. endredraw ();
GC-> deactivate ();

WS. Flush ();

Cleanupstack: popanddestroy (5, & ws); // window, GC, WG, screen, WS
}
Let's see now the entry point of the program. If we tried something like this
Now let's look at the entry program. If we do this:

Gldef_c tint e32main ()
{
_ Uheap_mark;
Ctrapcleanup * cleanup = ctrapcleanup: New ();

Trapd (error, exemainl ());
_ Assert_always (! Error, user: panic (_ L ("exeui"), error ));

Delete cleanup;
_ Uheap_markend;

Return 0;
}
It wocould work on the device only. On the emulator, you 'd get a panic,

Rwssession: connect () wowould fail. The reason for this is that when EXE is executed,

Emulator doesn' t launch the window server as part of its initialization, whereas on

Device the server is already loaded.
It can only run on a real machine (mobile phone. On the simulator, you will get a serious error because rwssession: connect () will be lost.

Failed. The reason is that when an EXE program runs on the simulator, it (simulator) will not start the window server as its initialization

. However, window servers always run on mobile phones.

There're a couple of ways to solve this. On Series 60 SDK v1.2, there's an unencrypted ented

Function which does exactly this for us. registerwsexe () is provided by wserv. Lib. So now

Our entry point function is:
There are many ways to solve this problem. In Series 60 SDK v1.2, an undisclosed function solves this problem for us.

Wserv. Lib provides the registerwsexe () function. Now our entry function:

Void registerwsexe (const tdesc &);

Gldef_c tint e32main ()
{
_ Uheap_mark;
Ctrapcleanup * cleanup = ctrapcleanup: New ();

# If defined (_ wins __)
Registerwsexe (_ L ("exeui.exe "));
# Endif

Trapd (error, exemainl ());
_ Assert_always (! Error, user: panic (_ L ("exeui"), error ));

Delete cleanup;
_ Uheap_markend;

Return 0;
}
The problem with this solution is that it's not as generic as we might want. There's

Another way, which requires some more bit of work, that consists of changing the target

Type to exedll or epocexe. This means that on wins (emulator) we get a. dll, and on marm

(Target) we get the. exe as usual. Note that all changes will be made to the startup code,

That is, no changes are made to exemainl () code.
This solution is not what we usually want. There is another way to do more work, including setting the target type

Change to exedll or epocexe. This means that we get .dllin the simulator, which is a common .exe on arm(mobile phone. Yes

Note that only the startup code exemainl () has not changed.

This is how our new startup code looks, with the two functions required by the exedll type

(Epocexe is analogous, doesn't the exported function initemulator () is replaced by winsmain

()):
The startup code looks like this. Below are the two functions required by exedll (epocexe is similar unless the export Function

Initemulator () is replaced by winsmain ):

Gldef_c tint e32main ()
{
_ Uheap_mark;
Ctrapcleanup * cleanup = ctrapcleanup: New ();

Trapd (error, exemainl ());
_ Assert_always (! Error, user: panic (_ L ("exeui"), error ));

Delete cleanup;
_ Uheap_markend;

Return 0;
}

// If using exedll target type
# If defined (_ wins __)
Export_c tint initemulator ()
{
E32main ();
User: exit (0 );
Return kerrnone;
}

Tint e32dll (tdllreason)
{
Return kerrnone;
}
# Endif
Now the idea is renaming exeui. DLL to exeui. app, and copying it to an application directory

On the emulator tree to make it look like an ordinary application. So we create the exeui

Directory in epoc32/wins/C/system/apps (or epoc32/release/wins/udeb/z/system/apps if you

Wish). As we're creating an application, we also need to provide it of a proper uid, so

Don't forget to add the corresponding line in the. MMP
Now you may launch the emulator, that will show the exeui program's default icon.
Now, you need to rename exeui. DLL to exeui. app and copy it to an application directory of the simulator. We

Create the exeui directory epoc32/wins/C/system/apps (or epoc32/release/wins/udeb/z/system/apps as long as you want

) Aren't we creating an application, so we need to provide a proper uid. Don't forget to go to the appropriate part of the. MMP file.

Add it. Now, when you start the simulator, it will display the default icon of the exeui program.