Adding Annunciators to the Taskbar Windows CE 4.2

Adding Annunciators to the Taskbar

If the fill H/PC-like shell is included, Windows CE supports the use of annunciators, icons placed onto the taskbar to indicate user notifications are active. Applications can add, change, and delete an annunciator using the Shell_NotifyIcon function. The following code example shows the prototype for this function.

BOOL Shell_NotifyIcon (DWORD dwMessage, PNOTIFYICONDATA pnid);

The first parameter, dwMessage, specifies the task the function should perform. This parameter can be one of the following three values:

NIM_ADD
This function adds an annunciator to the taskbar.
NIM_DELETE
This function deletes an annunciator from the taskbar.
NIM_MODIFY
This function modifies an existing annunciator on the taskbar.

The other parameter, pnid, points to the NOTIFYICONDATA structure. The following code example shows the structure definition.

typedef struct _NOTIFYICONDATA { 
   DWORD cbSize;
   HWND hWnd; 
   UINT uID; 
   UINT uFlags; 
   UINT uCallbackMessage; 
   HICON hIcon; 
   WCHAR szTip[64]; 
} NOTIFYICONDATA;

The first member, cbSize, contains the structure size, in bytes. The hWnd member specifies the window handle that owns the icon. This window receives messages notifying the window that a user has tapped, double-tapped, or moved a pen on the icon. The uID member identifies the icon being added, deleted, or modified. Assigning a uID to an icon enables an application to have more than one icon on the taskbar. The uFlags member contains flags that identify which of the remaining structure fields contain valid data.

The uCallbackMessage member contains an application-defined message identifier. Windows CE uses the identifier to notify the window specified in hWnd of any user actions on the icon. This value is based on WM_USER so that the message value does not conflict with other messages the window receives. The taskbar looks at uCallbackMessage only if uFlags contains the NIF_MESSAGE flag.

The hIcon member contains a handle to the icon to be displayed on the taskbar. Notification icons must be 16 x 16 pixels. Call the LoadImage function instead of the LoadIcon function to load the icon because LoadIcon does not return a small format icon. The taskbar looks at hIcon only if the NIF_ICON flag is set in uFlags. The last member, szTip, contains ToolTip text to display for the icon.

To effectively manage an annuciator, your application must handle any notification messages the taskbar sends to it. The wParam parameter of the message contains the identifier value of the taskbar icon that the message references. This identifier value is the same identifier defined in the call to the Shell_NotifyIcon function. The lParam parameter contains a code indicating the reason for the message. These values are actually the message codes for various mouse events. For example, if a user taps on a taskbar icon, the lParam value in the notification message will be WM_LBUTTONDOWN, followed by another message containing WM_LBUTTONUP.

 

GDI Support in Windows CE 4.2

 GDI Support

The GDI is the GWES subsystem that controls the display of text and graphics. Use GDI to draw lines, curves, closed figures, text, and bitmap images.

GDI uses a device context to store data that it requires to display text and graphics on a specified device. The graphics objects stored in a device context include a pen for line drawing, a brush for painting and filling, a font for text output, a bitmap for copying or scrolling, a palette for defining the available colors, and a clipping region. Windows CE supports printer device contexts for drawing on printers, display device contexts for drawing on video displays, and memory device contexts for drawing into memory.

The following table shows GDI features supported by Windows CE.

GDI feature
Description
Raster and TrueType fonts TrueType fonts are scalable and rotatable. Seven rasterized system fonts are available in several sizes in ROM. You can also add your own raster fonts. Windows CE supports only one category of font, either raster or TrueType, on a specified system.
Custom color palettes and both palletized and nonpalletized color display devices Supports color bit depths of 1, 2, 4, 8, 16, 24, and 32 bits per pixel (bpp). A bpp depth of 2 is unique to Windows CE.
Bit block transfer functions and raster operation codes Enables you to transform and combine bitmaps
Pens and brushes Supports dashed, wide, and solid pens, patterned brushes
Printing Supports graphics printing
Cursors Supports full use of cursors, including user-defined cursors, or the wait cursor
Shape drawing functions Supports the ellipse, polygon, rectangle, and round rectangle shapes

Windows CE GDI does not support the following features:

  • Transformation functions of coordinate space, such as SetMapMode, GetMapMode, SetViewportExt, and SetWindowExt. Coordinate space is equivalent to device space.
  • World Transform API
  • MoveTo and LineTo functions
  • Color cursors
  • Animated cursors

Application development in Windows CE Toolkit

Application Development

Microsoft provides several toolkits to assist you in developing Windows CE–based applications. These toolkits include the Microsoft® Windows® CE Toolkit for Visual C++® 6.0 and the Microsoft® Windows® CE Toolkit for Visual Basic® 6.0. The toolkits are add-ins to the Microsoft® Visual C++® and Microsoft® Visual Basic® development systems, which means that they use the IDE used to develop desktop applications. Microsoft packages the toolkits along with emulators to enable you to develop applications on a desktop computer.

Windows CE–based devices run different versions of the Windows CE OS and therefore support different toolkits. For example, if you want to use Visual Basic to create an application for an H/PC running Handheld PC Pro Edition software, you need the following products:

  • Microsoft Visual Basic 6.0 development system
  • Microsoft Windows CE Toolkit for Visual Basic 6.0
  • Microsoft Windows CE Platform SDK, Handheld PC Edition, version 2.0

Both the development system and the toolkit are available through standard retail channels; the SDK is distributed on the Windows CE Web site.

The following table shows the toolkits that are available for each platform.

Windows CE–based devices span the home entertainment, vertical device, and PC companion markets. In the home entertainment market, products that run Windows CE include the Sega Dreamcast system, Internet set-top boxes, and Web telephones. In the vertical device market, embedded systems developers provide custom-built computers designed for special tasks, such as package and mail tracking devices, point-of-sale terminals, and navigation devices. In the PC companion market, products that run Windows CE include the H/PC, the Palm-size PC, and the Auto PC.

Each device category supports a different set of APIs. Within each device category, what is supported depends on the version of the OS that the device is built on and what modules and components are included. In addition, each device category contains a unique shell with its supporting APIs. Therefore, a Windows CE–based platform can contain APIs that are not included in the core Windows CE OS.

Additionally, Windows CE differs based on how it is ported to a device. While all H/PCs of a particular version may have the same set of functions, the functions available on a Palm-size PC differ from those on an H/PC. In addition, OEMs have the option of removing optional sections of the OS, so configuration of the OS running on a specific device can vary significantly.

Creating and Terminating a Thread in Windows CE 4.2

 Creating and Terminating a Thread

To create a thread, call the CreateThread function. The following code example shows the CreateThread function prototype.

HANDLE CreateThread(LPSECURITY_ATTRIBUTES lpThreadAttributes,
DWORD dwStackSize, LPTHREAD_START_ROUTINE lpStartAddress,
LPVOID lpParameter, DWORD dwCreationFlags, LPDWORD lpThreadId );

Because Windows CE does not support the lpThreadAttributes and dwStackSize parameters, you must set them to NULL or 0. The following table describes the remaining CreateThread parameters.

Parameter
Description
lpStartAddress Points to the start of the thread routine
lpParameter Specifies an application-defined value that is passed to the thread routine
dwCreationFlags Set to 0 or CREATE_SUSPENDED
lpThreadId Points to a DWORD that receives the new thread's identifier

If CreateThread is successful, it returns the handle to the new thread and the thread identifier. You can also retrieve the thread identifier by calling the GetCurrentThreadId function from within the thread. In Windows CE, the value returned in GetCurrentThreadId is the actual thread handle. You can also retrieve a handle to the thread by calling the GetCurrentThread function. This function returns a pseudo-handle to the thread that is valid only while in the thread. If you specify CREATE_SUSPENDED in the dwCreationFlags parameter, the thread is created in a suspended state and must be resumed with a call to the ResumeThread function.

You can terminate a thread by calling ExitThread, which frees the resources that are used by a thread when they are no longer needed. Calling ExitThread for an application's primary thread causes the application to terminate.

Creating a Process in Windows CE 4.2

 Creating a Process

To start a process from within another process, call the CreateProcess function, which loads a new application into memory and creates a new process with at least one new thread.

The following code example shows the CreateProcess function prototype.

BOOL CreateProcess(LPCTSTR lpApplicationName,
LPTSTR lpCommandLine,
LPSECURITY_ATTRIBUTES lpProcessAttributes,
LPSECURITY_ATTRIBUTES lpThreadAttributes,
BOOL bInheritHandles, DWORD dwCreationFlags, LPVOID lpEnvironment,
LPCTSTR lpCurrentDirectory, LPSTARTUPINFO lpStartupInfo,
LPPROCESS_INFORMATION lpProcessInformation );

Because Windows CE does not support security or current directories and does not handle inheritance, the majority of the parameters must be set to NULL or 0. The following code example shows how the function prototype would look when all nonsupported features are taken into consideration.

BOOL CreateProcess(LPCTSTR lpApplicationName,
LPTSTR lpCommandLine, NULL, NULL, FALSE,
DWORD dwCreationFlags, NULL, NULL, NULL,
LPPROCESS_INFORMATION lpProcessInformation );

The first parameter, lpApplicationName, must contain a pointer to the name of the application to start. Windows CE does not support passing NULL for lpApplicationName and looks for the application in the following directories, in the following order:

  1. The path specified in lpApplicationName, if one is listed.
  2. An OEM-specified search path.
  3. The Windows directory (\Windows).
  4. The root directory in the object store (\).

The lpCommandLine parameter specifies the command line to pass to the new process. The command line must be passed as a Unicode string. The dwCreationFlags parameter specifies the initial state of the process after loading. The following table describes all of the supported flags.

Flag
Description
0 Creates a standard process.
CREATE_SUSPENDED Creates a process with a suspended primary thread.
DEBUG_PROCESS Creates a process to be debugged by the calling process.
DEBUG_ONLY_THIS_PROCESS Creates a process to be debugged by the calling process, but doesn't debug any child processes that are launched by the process being debugged. This flag must be used in conjunction with DEBUG_PROCESS.
CREATE_NEW_CONSOLE Creates a new console.

The last parameter used by CreateProcess is lpProcessInformation. This parameter points to the PROCESS_INFORMATION structure, which contains data about the new process. The parameter can also be set to NULL.

If the process cannot run, CreateProcess returns FALSE. For more information about the failure, call the GetLastError function

Building the F# Compiler Nov 2013 from Microsoft Open Technologies

F# 3.1 Compiler matching Visual Studio 2013  RTM binary release

This directory contains a drop of the source code for an F# 3.1 compiler and core library. The code has been cleaned up "a little" to try to help ensure better stability as more development is done on the codebase.

The compiler is normally compiled as a set of .NET 4.0 components.

Before we start, are sure you're in the right place?

To emphasize, this distribution should not be seen as a way to "get" an F# compiler for immediate use. For that you're better going to fsharp.org.

License: subject to terms and conditions of the Apache License, Version 2.0. A copy of the license can be found in the License.html file at the root of this distribution. By using this source code in any fashion, you are agreeing to be bound by the terms of the Apache License, Version 2.0. You must not remove this notice, or any other, from this software.

Questions? If you have questions about the source code, please ask at the F# Open Source Google Group. Please do not ask the F# team at Microsoft for help with this source code: they like to be friendly, but they are very busy working on improving F# and need to focus on that.

Updates? The F# team do not do active development in open repositories, though some changes such as cleanup or additional tools may be submitted. They aspire to update the code drop when future versions of F# compilers are released from Microsoft, usually at or around the RTM stage.

Copyright: Copyright 2002-2012 (c) Microsoft Corporation.

What do I get when I compile?

When you build the compiler using the standard instructions below, you get fsc.exe, fsi.exe, FSharp.Core.dll, FSharp.Compiler.dll and some related DLLs.

The compiler binaries produced are "private" and strong-named signed with a test key (src\fsharp\test.snk). They use CLI assembly version nunmber 2.9.9.999. You can place these components in the GAC but they will not replace the components used by normal Visual Studio or normal F# programs.

Steps - Building a Proto Compiler

  cd src 
  gacutil /i ..\lkg\FSharp-2.0.50726.900\bin\FSharp.Core.dll
  msbuild fsharp-proto-build.proj

Note: Make sure you run the .NET 4.0 msbuild.exe, e.g. C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe.

Optional: NGEN the Proto Compiler for faster future startup (optional)

ngen install ..\Proto\net40\bin\fsc-proto.exe

Steps - Building the F# Core Library

This uses the proto compiler to build the FSharp.Core library, for Mono/.NET 4.0.

msbuild fsharp-library-build.proj /p:TargetFramework=net40
msbuild fsharp-library-build.proj /p:TargetFramework=net20

Note: Make sure you run the .NET 4.0 msbuild.exe, e.g. C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe.

Steps - Building the F# Compiler

This uses the proto compiler to build the FSharp.Compiler.dll and fsc.exe to run on for Mono/.NET 4.0.

msbuild fsharp-compiler-build.proj /p:TargetFramework=net40

Note: Make sure you run the .NET 4.0 msbuild.exe, e.g. C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe.

Notes on the build

The prerequisites and build command line for compiling the source (on Windows) are shown later in this README. Here's the logic of the build:

  • We first need an existing F# compiler, using the one in the 'lkg' directory. Let's assume this compiler has an FSharp.Core.dll with version X.
  • We use this compiler to compile the source in this distribution, to produce a "proto" compiler, in the Proto directory. When run, this compiler still relies on the FSharp.Core.dll with version X.
  • We use the proto compiler to compile the source for FSharp.Core.dll in this distribution, producing an FSharp.Core.dll with the version identified in src\source-build-version, usually 1.9.999.
  • We use the proto compiler to compile the source for FSharp.Compiler.dll, fsc.exe, fsi.exe and other binaries found in this distribution. When run, these binaries will rely on the FSharp.Core.dll with version 1.9.999. This is good, since it means the 1.9.999 binaries now form a consistent, bootstrapped compiler. If you like you should now be able to throw away the compiler with version X.

Some additional tools are required to build the compiler, notably fslex.exe, fsyacc.exe, FSharp.PowerPack.Build.Tasks.dll, FsSrGen.exe, FSharp.SRGen.Build.Tasks.dll and the other tools found in the lkg directory. These are "Last Known Good" binaries created from a version of the F# Power Pack on CodePlex. If you like you can throw away these binaries and use your own compiled versions of these. tools.

Use

Here are some simple tests to validate what you have built by checking fsi.exe (F# Interactive) starts up:

ngen install ..\Debug\net40\bin\fsi.exe
..\Debug\net40\bin\fsi.exe
1 + 1;;
#q;;
..\Debug\net40\bin\fsi.exe /help
..\Debug\net40\bin\fsc.exe /help
echo printfn "hello world" > hello.fs
..\Debug\net40\bin\fsc.exe hello.fs
copy ..\Debug\net40\bin\FSharp.Core.dll .
hello.exe
del /q FSharp.Core.dll 

Some alternative Steps - Building an optimized (Release) compiler for .NET 4.0 profile

msbuild fsharp-compiler-build.proj /p:TargetFramework=net40 /p:Configuration=Release

ngen install ..\Release\net40\bin\fsi.exe
..\Release\net40\bin\fsi.exe
1 + 1;;
#q;;
..\Release\net40\bin\fsi.exe /help
..\Release\net40\bin\fsc.exe /help
echo printfn "hello world" > hello.fs
..\Release\net40\bin\fsc.exe hello.fs
copy ..\Release\net40\bin\FSharp.Core.dll .
hello.exe
del /q FSharp.Core.dll