Bagikan melalui

Announcing ScreenLib - a free UI development library!

  • Artikel

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:
https://www.microsoft.com/downloads/details.aspx?FamilyID=a908dd7f-71c0-4cea-b97d-b9ffe985f903&displaylang=en

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!

ScreenLib.zip

Comments

  • Anonymous
    September 11, 2006
    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
    Tom

  • Anonymous
    September 11, 2006
    See the original description (keyword 'native'):

    "...a new library for native Windows Mobile developers"

  • Anonymous
    September 11, 2006
    PingBack from http://edablog.com/2006/09/11/eda-news-20060911/

  • Anonymous
    September 11, 2006
    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?

  • Anonymous
    September 11, 2006
    The comment has been removed

  • Anonymous
    September 11, 2006
    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.

  • Anonymous
    September 11, 2006
    Matthew:
    On Windows Mobile-based Smartphones, only Internet Explorer Mobile has command buttons. All other applications use soft keys. This is from the Smartphone SDK.

  • Anonymous
    September 11, 2006
    The comment has been removed

  • Anonymous
    September 12, 2006
    MelSam:

    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.

  • Anonymous
    September 13, 2006
    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.

  • Anonymous
    September 13, 2006
    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.

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

  • Anonymous
    September 14, 2006
    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.

  • Anonymous
    September 14, 2006
    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.

    -Mel

  • Anonymous
    September 27, 2006
    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

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

  • Anonymous
    October 08, 2006
    Thanks what looks like a great library. Where can I get DRA::SCALEX from? Thanks 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

  • Anonymous
    October 08, 2006
    Mark: 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.

  • Anonymous
    October 08, 2006
    MelSam: 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.

  • Anonymous
    December 14, 2006
    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.

  • Anonymous
    December 14, 2006
    Ah, nevermind it's DeviceResolutionAware.h.

  • Anonymous
    January 14, 2007
    The comment has been removed

  • Anonymous
    January 24, 2007
    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 = rcCtl.top;    nWidth = rcCtl.right - rcCtl.left;    nHeight = rcCtl.bottom - rcCtl.top;    break;  case dtRight:    nLeft = (rcClient.right - rcClient.left) - (rcCtl.right - rcCtl.left);    nTop = rcCtl.top;    nWidth = rcCtl.right - rcCtl.left;    nHeight = rcCtl.bottom - rcCtl.top;    break;  case dtTop:    nLeft = rcCtl.left;    nTop = 0;    nWidth = rcCtl.right - rcCtl.left;    nHeight = rcCtl.bottom - rcCtl.top;    break;  case dtBottom:    nLeft = rcCtl.left;    nTop = rcClient.bottom - (rcCtl.bottom - rcCtl.top);    nWidth = rcCtl.right - rcCtl.left;    nHeight = rcCtl.bottom - rcCtl.top;    break;

  • Anonymous
    April 18, 2007
    i need to chege my win mo os ,defat laguage is italy ,ineed to change it to english

  • Anonymous
    August 21, 2007
    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?

  • Anonymous
    October 18, 2007
    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 ;)

  • Anonymous
    October 18, 2007
    That is no OptimizeHeight() for multiple controls.

  • Anonymous
    April 17, 2008

  • GPS Signal Quality - Error Reduction - Avoid problems with localizations - Data Layer: do NOT use XML