Announcing ScreenLib – a free UI development library!

Today I'm pleased to announce ScreenLib, a new library for native Windows Mobile developers. It takes away a lot of the pain of designing user interfaces for multiple screen sizes, orientations, form factors etc. It lets you create a user interface once and have it automatically adapt to whatever the device’s screen size is at runtime. By doing this, it offers basic docking & anchoring support for native development and can do a lot of UI plumbing work with just 1 or 2 lines of code.

ScreenLib works on Pocket PC and Smartphone devices, so it's a great step towards creating single binaries that will run on both platforms.

I highly recommend watching a video tutorial that explains how ScreenLib works and why it should be used. To download the video, please visit:

ScreenLib is attached to this post. Download it and let us know what you think. Our plan is to include it in the next version of the Windows Mobile SDK, so we greatly appreciate your feedback to improve it. Enjoy!

Comments (30)

  1. TomS says:

    The video tutorial project was an MFC project.  It would be helpful to have an example in C# or VB.NET as well.

    Thank you


  2. ajh says:

    See the original description (keyword ‘native’):

    "…a new library for native Windows Mobile developers"

  3. What software license applies to this class?  Can it be used inside commercial product applications for Windows Mobile?  In the ScreenLib header and source file is says "For a copy of the EULA, please see the LICENSE.RTF on your install media."  Can you tell me where to find LICENSE.RTF or post it?

  4. Matthew says:

    This sounds great, but skimming the code I see obvious problems immediately. For example, the code to align button is ifdefed out on Smartphone with the comment that buttons are not used on Smartphone. WTF!? Butons are most certainly used, and not just in my code. Take a look at a webpage with a button in PIE and behold, a button on the screen. So, they are definitely used by Microsoft themselves, yet us ISVs should not use them? I guess we also aren’t suppossed to let people exit our programs either, but any decent application will allow it.

  5. IANAL says:

    Since the EULA is claimed to be in a non-existant file, that means the EULA is non-existant. The test accompanying the copyright states that use is permitted subject to the terms of the license, which being a zero terms license, is easy to accept. Meaning, it is publically useable for whatever you wish, just so long as you don’t attempt to change the copyright.

    If Microsoft attempts to claim that they meant to include a license that does not change the fact its already been distributed without one. If the downloadable file is changed to include a license, then all new downloads would be covered by that license, but the previously available file could still be freely redistributed to anyone desiring it as there were no restrictive licensing terms to prevent that.

  6. MSDNArchive says:


    On Windows Mobile-based Smartphones, only Internet Explorer Mobile has command buttons. All other applications use soft keys. This is from the Smartphone SDK.

  7. Sebastian says:

    Very nice.

    But I had to "port it" to eVC4.  🙁

    DRA:: stuff and __fallthrough are not supported out of the box.  I had to move UIHelper.* code files from other sample projects to get such support.

    But it’s great to finally get some support with this stuff instead of coding my own.  I await the next update.

  8. Matthew says:


    The Smartphone SDK in no way hinders my use of buttons in porting applications from PocketPC. They do not appear unsupported in any way. Senselessly unsupported seems reserved for other basic things, like file dialogs.

  9. MSDNArchive says:

    Matthew: You won’t be hindered from using buttons, but it is not an acceptable practice to use buttons in SP apps. You won’t find any built-in apps (except IE) doing it because it causes usability issues. IE supports buttons because it allows you to view ANY website from the Internet – even those that are not specifically designed for mobile devices.

  10. Matthew says:

    MelSam: Which is my point, the SDK does NOT impose a limitation on button use, so saying the ScreenUI does not handle buttons on Smartphone due to the SDK makes no sense. Its just impossing yet anothr useless restriction. If you wanted to do something to ease cross-platform development, then give us something to make the buttons automagically be menu items on Smartphone.

    As it is, the UI on the two platforms is almost completely different. In porting to Smartphone, almost the entire UI has had to change and for no good reason. A sane API would make this easy to deal with. The only comminality between PocketPC and Smartphone is the overall trashiness of the GUI. Burdening developers with artificially incompatible interfaces does nothing but waste our time. A sane GUI toolkit that we could write to in order to target both devices would lift the burden. This ScreenUI lib instead merely reinforces the separation.

  11. El Bruno says:

    Buenas, después de jugar un poco con el Smart Client Software Factory , gracias a Carlos he encontrado

  12. Bill C says:

    A suggested enhancement would be API to deal with what your failed first demo attempt with the progress bar.  Perhaps a ‘FitAvailableSpace’ type api which factored in the siblings location and not just the parent size or borders.  The slider really needs to look at its sibling (the Button) final resting place and then resize its width up to the point where it has the nice stretched width (i.e. ‘available space’).  

    Another suggestion would be an overall set of preferences for white space that could be global set for a variety of esthetics so these don’t have to be nudged around at design time over and over again.  Such as preferred distance from left, right, top, bottom of (dialog) parents, etc and preferred distance between controls.  May be necessary to have preferences by control type as a global setting for all types of children controls may be too general.  

    Another suggestion would be a way to mark the design time controls as no-size or zero size so that you don’t get that ugly resize effect on the first run as you see the controls resize from their initial design time defaults.  In your demo you can see the original design time settings for a brief split second before they go resize.  It’s uglier than it should have to be.  

    I like the variable args approach in your API.  Perhaps as the API is enhanced, if a child control is sort of an anchor to more sophisticated prioritization, you could use the variable args to attribute how you want a certain control to affect other controls in the layout.  In the demo, you really wanted the OK button to float along the right end of the search text field, and then the right border of the progress bar to float from the left side of the OK button back to the left all the way to left border of the dialog.  A combination of some more Win32 code and an elegant way to express these rules with the control IDs, would be powerful.

  13. MSDNArchive says:

    Bill C:

    Thanks for the feedback. After the video was recorded, I added a couple more functions that allow adding a button to the right of the progress bar. Take a look at the source code attached to this post. It was updated since the video, and has some more features.


  14. Mel Sampat from the Windows Mobile team blogged about a new UI management library, called ScreenLib, that dramatically simplifies creating native user interfaces for Windows Mobile applications: [ScreenLib] takes away a lot of the pain of designing user

  15. El Bruno says:

    Buenas, después de jugar un poco con el Smart Client Software Factory , gracias a Carlos he encontrado

  16. Mark says:

    Thanks what looks like a great library. Where can I get DRA::SCALEX from?


    Error 2 error C2653: ‘DRA’ : is not a class or namespace name c:DevProjectsWords2Words2ScreenLib.cpp 243

    Error 3 error C3861: ‘SCALEX’: identifier not found c:DevProjectsWords2Words2ScreenLib.cpp 243

  17. MSDNArchive says:


    DRA is part of the SDKs that ship with Visual Studio 2005. Are you compiling with VS2005 or some other IDE? FYI, ScreenLib is not supported on eVC or anything other than VS2005.

  18. Mark says:


    I’m trying to use ScreenLib in a WTL CE project using VS2005. The deafult WTL project doesn’t seem to include the DeviceResolutionAware.h which was causing the above problems.

    Btw, are you familiar with WTL’s CDialogResize?

    If so when would you choose one or the other?

    Thanks for your help.

  19. Marvin Bellamy says:

    Where EXACTLY is DRA and SCALEX defined?  I’m building with Visual Studio 2005 Pro and I’m getting the same error messages Mark mentioned.  I’ve also grepped the headers and SDKs and not seen DRA defined.

  20. Marvin Bellamy says:

    Ah, nevermind it’s DeviceResolutionAware.h.

  21. I’ve been using ScreenLib, there are a couple of issues.

    [1] If you use it to position a combo box, you loose the combo box hieght used for the drop down. I’ve fixed this by adding in some code that checks for combos, and times it by 5.

    int controlHeight = rcCurrent.bottom –;

    TCHAR buffer[256] ={0};


    if (lstrcmpi(buffer,L"combobox")==0) controlHeight*=5;

    ::MoveWindow(hwndIDCurrent, nMargin, ptMoveTo.y,

     nNewCtlWidth, controlHeight, TRUE);

    [2] If you use it position a listbox with a buddy control, you loose the buddy controls position. I fixed this by reattaching the buddy after screenlib has sized the list box. I couldn’t think of how to get screen lib to recognize a listbox has a buddy control and get it to do the work.

    Otherwise it a useful lib.

  22. Jason Willcox says:

    Very useful lib, one issue with DockControl() I found:

    The size and positions of the ctrl is incorrect for:

    dtLeft, dtRight, dtTop, and dtBottom, they are mistakenly using the screen width/height for the width/height of the control, and docking in the top left corner for both dtLeft and dtTop.

    My fix:

     case dtLeft:

       nLeft = 0;

       nTop =;

       nWidth = rcCtl.right – rcCtl.left;

       nHeight = rcCtl.bottom –;


     case dtRight:

       nLeft = (rcClient.right – rcClient.left) – (rcCtl.right – rcCtl.left);

       nTop =;

       nWidth = rcCtl.right – rcCtl.left;

       nHeight = rcCtl.bottom –;


     case dtTop:

       nLeft = rcCtl.left;

       nTop = 0;

       nWidth = rcCtl.right – rcCtl.left;

       nHeight = rcCtl.bottom –;


     case dtBottom:

       nLeft = rcCtl.left;

       nTop = rcClient.bottom – (rcCtl.bottom –;

       nWidth = rcCtl.right – rcCtl.left;

       nHeight = rcCtl.bottom –;


  23. Ranamuka says:

    i need to chege my win mo os ,defat laguage is italy ,ineed to change it to english

  24. Anton says:

    The ScreenLib has very serious design limitations both in the controls layout management and in the code design.

    I failed to get the my design properly aligned and sized – ScreenLib provides only top/bottom/left/right management, I cannot describe the exact controls layout.

    The code is also not always good. What is the reason to have ‘…’ parameters avoiding liker checks, when we can use things like UINT NumberOfControls, UINT *ControlsArray? What if I have array of controls, should I list the whole array elements in a single function call and have a function call with 20 parameters?

    What’s the reason to use ASSERTS for error management instead of regular error checking?

  25. DJ says:

    What a con 🙂

    You use the listbox on your video demo to evenly fill the vacant vertical space as you have no OptimizeHeight().

    Why didn’t you write one?

    Never mind i’ll do it myself 😉

  26. DJ says:

    That is no OptimizeHeight() for multiple controls.

  27. – GPS Signal Quality – Error Reduction – Avoid problems with localizations – Data Layer: do NOT use XML

Skip to main content