Dialog size in pixel
Erakis
I have to draw/set a bitmap as background of my dialog.
This is like a skinned application. For that, I need to set the dialog size
to 340x234 "pixels" and not"Base unit" like resource do.
Also I will have to add others components on this dialog like
(Button,TextBox, Label, ListBox, etc...) at a specified position in pixels
sothat they fit on the background image.
If user change de display settings "DPI", the dialog size will changeand I
don't want that ! Because the position/dimension of bitmaps onmy dialog will
no longer fit.
Is someone have any clues/suggestion to help me with that problem ?
Regards,
Tom Serface
http://msdn.microsoft.com/en-us/library/ms645502(VS.85).aspx
Tom
"Erakis" <Era...@discussions.microsoft.com> wrote in message
news:28C0C07B-3012-46FD...@microsoft.com...
David Ching
news:28C0C07B-3012-46FD...@microsoft.com...
You're stuck with dialog units in the resource editor. But you can fix the
locations/size of the dialog and its controls as it is displayed. In
OnInitDialog(), call MoveWindow() with the desired size, e.g. 340x234. In
OnMove(), move all the child controls to the desired pixel locations.
-- David
Erakis
I know that I can Move and Size my windows at runtime. But do you imagine
that I will need to do that way for 80 dialogs and each of their component
without beeing able to do it in design mode !!! I mean in blind way...
Why when using Visual Studio .NET C# or Delphi Win32 we can set the windows
size while designing and not with MFC ??? It is absurd !!!
David Wilkinson
> Hi and thanks for your help, I appreciate it.
>
> I know that I can Move and Size my windows at runtime. But do you imagine
> that I will need to do that way for 80 dialogs and each of their component
> without beeing able to do it in design mode !!! I mean in blind way...
>
> Why when using Visual Studio .NET C# or Delphi Win32 we can set the windows
> size while designing and not with MFC ??? It is absurd !!!
Erakis:
Just one of those "close to the Win32 metal" features of MFC that you have to
get used to.
You will certainly want to write yourself a function that will resize any dialog
by looping through the child controls and moving them as appropriate. This is no
different from what you may need to do if you have a resizable dialog or CFormView.
--
David Wilkinson
Visual C++ MVP
Erakis
But it is possible to set a FIXED font size to the dialog so that the size
in pixel of my Dialog will be the same on two different computer ?
Serge Wautier
This might be a big hammer for a small nail but who knows: Is a .NET
WinForms app an option? They don't use dialog units.
My 2-cents,
Serge.
http://www.apptranslator.com - Localization tool for your MFC applications
"Erakis" <Era...@discussions.microsoft.com> wrote in message
news:D39209AD-C0F3-439D...@microsoft.com...
Tom Serface
http://www.codeproject.com/KB/dialog/bmpdlg01.aspx
If you need to put controls on the background then Ali's article might be of
interest to you. Buttons are easy since they don't have a lot of open
space, but you will want static controls to be transparent:
http://www.codeproject.com/KB/static/TransparentStaticCtrl.aspx
Another way of controlling how the dialog resizes is to use a layout manager
like:
http://www.codeproject.com/KB/dialog/resizabledialog.aspx
And, you could fix the size of the dialog so that users can't move it if
you don't want the bitmap to be resized to a funny shape.
Tom
"Erakis" <Era...@discussions.microsoft.com> wrote in message
news:D39209AD-C0F3-439D...@microsoft.com...
Tom Serface
the size of the dialog. Your dialogs, unless resized by users, should be
the same size on different computers.
If you just want the font to be the same the same font would have to be
available on all computers where you application runs or a close one will be
substituted in for you. I'd pick a font that is available in the normal
install of Windows.
I had a problem with something similar recently. I thought if I switched to
Microsoft San Serif that I could use the same font for all languages, then
it turned out the same font name on Win 2K didn't have Japanese characters
(I guess they added them in more recent versions of Windows). However, the
English was the same on all. If you really want to be sure you could just
install your own font as part of your setup.
Tom
"Erakis" <Era...@discussions.microsoft.com> wrote in message
news:7165CA15-81FB-42B3...@microsoft.com...
Tom Serface
the dialog un-resizable then you can change the border in the properties
easily to do that.
Tom
"Erakis" <Era...@discussions.microsoft.com> wrote in message
news:7165CA15-81FB-42B3...@microsoft.com...
David Ching
> Hi and thanks for your help, I appreciate it.
>
> I know that I can Move and Size my windows at runtime. But do you imagine
> that I will need to do that way for 80 dialogs and each of their component
> without beeing able to do it in design mode !!! I mean in blind way...
>
> Why when using Visual Studio .NET C# or Delphi Win32 we can set the
> windows
> size while designing and not with MFC ??? It is absurd !!!
>
What I've done is written a CBaseDlg which derives from CDialog, and that
handles all the moving and resizing based on an XML file containing location
and size info for each dialog and its controls. That makes it easier.
Win32/MFC is married to this dialog unit concept, which was invented long
before it was cool to skin your apps.
-- David
Erakis
What I want is to be sure that if I draw a bitmap of "340x234" (as
background) pixels on my Dialog and I sucessfully find the Dialog "BaseUnit"
size fitting with the Background size. I want that result be the same on all
computer.
As exemple, if I set my Dialog size to "120x70" "base unit" and my
background fit exactly on that size. I hope that Dialog size will be the same
on all computer so that the background fit. I don't want to start programming
stretching algo...
Erakis
use base unit ??? It's a lot of trouble managing skinned application !
I don't want to use .NET. In the past I already made an application having
more than 150 forms. Hopefully designing application was really quick but the
execution was really TO SLOW. I mean transition between forms. We attemp to
build a cache to correct the problem but the gain was not enought for our
need.
Mihai N.
>
> I have to draw/set a bitmap as background of my dialog.
>
> This is like a skinned application. For that, I need to set the dialog size
> to 340x234 "pixels" and not"Base unit" like resource do.
I would not use such an application.
It will waste most of my 640x480 screen.
Having fixed pixel size dialogs is really bad user experience.
--
Mihai Nita [Microsoft MVP, Visual C++]
http://www.mihai-nita.net
------------------------------------------
Replace _year_ with _ to get the real email
Tom Serface
computers (well PCs anyway). All PCs have the same pixel size. It would be
different on a Mac of course. You'd have to limit the dialog so it couldn't
be resized, but that's just a properties setting. You could add the picture
to your resources and simply drop it on the dialog then resize the dialog to
fit the picture (visually). Even though the picture is in pixels it will
still show up on the dialog. You could also use the test dialog button to
pop up the dialog during design time to see what it will look like at run
time. I've done this on a few applications (mostly in splash screens).
Tom
"Erakis" <Era...@discussions.microsoft.com> wrote in message
news:C76AE98B-9FB9-439E...@microsoft.com...
David Ching
news:Xns9AC4E495...@207.46.248.16...
> I would not use such an application.
> It will waste most of my 640x480 screen.
>
> Having fixed pixel size dialogs is really bad user experience.
>
It depends on the audience. For LOB or creative apps, of course you want as
much real estate as possible to work with your data. For other things
(where just figuring out what to do and not operating on a lot of data, or
setting just a few settings), having a really jazzy UI, even if it is fixed
size, seems to do the job better. Examples are Nero SmartStart and other
'chooser' apps for massive suites which jam a lot of disjointed apps into
one box, and the user doesn't even know which Start menu icon to click to do
what he or she wants. Yes, Logitech SetPoint fits into this also. ;)
-- David
Tom Serface
resize everything based on the the size the user sets for it, but I do have
a few things that I fix the size on just because, like OP, I want it to look
nice and don't want a typical Windows look. I'm glad we have the
flexibility to do all kinds of applications.
Tom
"David Ching" <d...@remove-this.dcsoft.com> wrote in message
news:OQ87k.10728$uE5....@flpi144.ffdc.sbc.com...
Henryk Birecki
>As exemple, if I set my Dialog size to "120x70" "base unit" and my
>background fit exactly on that size. I hope that Dialog size will be the same
>on all computer so that the background fit. I don't want to start programming
>stretching algo..
If you set the Dialog size to units based on fonts then yes it will be
the same size on all PDAs. If you set it in pixels it will not. You do
not need to program stretching algorithms. All you neet to do is to
use StretchBlt insteat of BitBlt. Most (maybe not all) PDAs will
support legacy non-resolution aware programs (without CEUX resource)
and pretend to be 92dpi screens but on these StretchBlt will be the
same as BitBlt
Cheers,
Henryk
Serge Wautier
by 10 years or so.
The people who decided to base dialog units on average font size had a very
good point. Skinning was not really a common thing back then.
Now, over time, the evolution showed that these dialog units were not the
panacea and the people who invented .NET decided that pixels are a better
unit. Do you want then to have kept with the past, iow dialog units?
Of course, this doesn't mean that pixels are *always* a better unit.
.NET (especially .NET CF) is indeed rather slow.
Serge.
http://www.apptranslator.com - Localization tool for your MFC applications
"Erakis" <Era...@discussions.microsoft.com> wrote in message
news:6A4E14F9-6614-4F63...@microsoft.com...
Mihai N.
> size, seems to do the job better. Examples are Nero SmartStart and other
> 'chooser' apps for massive suites which jam a lot of disjointed apps into
> one box, and the user doesn't even know which Start menu icon to click to
> do what he or she wants.
Oh, don't get me started on those! I absolutely hate Nero SmartStart and most
others chooser apps. Why Start - Nero - SmartStart then identifying an icon
out of 20 is faster than Start - Nero - identify link out of 20?
It is one click extra, waiting for the start of an extra app, and still
not saving me the selection step.
I find a Control-Panel look works ok for that kind of stuff, if need be.
No need for something that does not look like anything else I know.
Personally, I am by default against skins and custom controls in general.
Standard controls have years of refinments:
They respect my font/color/theme preferences in Control Panels.
Do the right thing for international users.
Respect all the standard accelerators.
Handle tabs, quick-keys and accelerators properly.
Work well with accessibility tools (like screen readers).
Just play with an edit control.
Press RCtrl-RShift and LCtrl-LShift to change context to RTL/LTR.
When you have a RTL keyboard installed (try Arabic or Hebrew) the cursor
changes slighly. The I-Bean has like a small "flag" at the top showing you
the current direction for the context.
When set to be a password control, it disables the IME (the right thing).
And many other small details, that someone spend millions on user research.
So replacing it with some "fancy bitmap crap" is always going to loose some
of those details, a bad idea in my book.
Mihai N.
Not quite so.
Just think about this:
- my T61p laptop has a 15.4" screen with a resolution of 1920 x 1200
- for my desktop I still have an old 19" Viewsonic, at 1280 x 1024
Just divide the width of the screen to the horizontal resolution to
get the pizel size.
Or, to put it differently: a fixed-size application (in pixels) that
is 800x600 is about 2/3 of my desktop screen. But it is less than 1/2
of my laptop screen. And the laptop scren is smaller in size.
So what looks ok on my desktop is unreadable on my laptop.
David Ching
Yeah, as an Engineer, I totally agree. But the fact is, many skinned apps
are not designed for engineers. They are designed for soccer moms who don't
know what LTR is and don't care. They just want to burn a CD and if the
only way they can do that is to put a giant icon with "Burn an audio CD you
can listen to in your car" is the only way they can figure it out, well...
that is one audience for skinned apps.
For whatever reason, I am hired to do a lot of those kinds of things.
-- David
Joseph M. Newcomer
square and some are rectangular. Therefore, it is not possible to set "a" size that works
on all CE platforms.
Base units and other stuff have NOTHING to do with this; it is the size of the screen that
dictates the parameter, unless you simply want to create a bitmap that is as small as the
smallest possible CE platform, and then make the dialog smaller than the screen size on
all but that one model of handheld.
There is no way adding things at "specific pixel positions" can make sense in an
environment in which screens are different sizes (I have three different handhelds that
use CE, and each of them has a different-sized screen!) Therefore, you cannot create a
background for which this is possible which will work on all possible screens. About ten
years ago I had a client that was the victim of this kind of design; they had an app that
worked "full-screen" which everyone "knew" was 640x480. Of course, modern laptops started
having different sizes, and they wanted the background to be perfect on ALL screens.
Ultimately, they ended up with a completely unmaintainable mess, which I had to fix. The
way I fixed it was to get rid of the "cute" background and just create a dialog with
controls, which would dynamically resize to be full-screen. Control sizes and positions
were adjusted to give even spacing. Generally, creating cute backgrounds is a way of
making life miserable.
If you are running on exactly one known CE platform, you go into the dialog editor, and
create a dialog and put the controls on it. No big deal. Just like you would any dialog.
Then in OnInitDialog, you will do SetWindowPos to adjust the position and/or size of these
windows to match your background. If you do a single Create() call to create the
controls, you have gone to great lengths to make your life miserable.
Of course, this app can run on exactly ONE model of CE platform, or that's the best you
can hope for. There is a slight chance some other brand of CE platform, or some other
model, *might* have the same screen size, but given my experience, CE platforms are going
the way of every other platform: each new platform has a larger screen and higher
resolution than the one before it, limited only by the form factor.
joe
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Joseph M. Newcomer
Seriously, doing hand-layout of 80 dialogs so they all meet some bitmap template seems to
be overkill.
joe
Mihai N.
> They are designed for soccer moms who don't
> know what LTR is and don't care.
Moms speaking Arabic or Hebrew care about LTR.
> if the only way they can do that is to put a
> giant icon with "Burn an audio CD you can listen
> to in your car" is the only way they can figure it out,
> well... that is one audience for skinned apps.
That kind of design is not what it takes for people to use something.
That is the "Experience Designer" justifying it's salary.
A *standard* button with an icon is not a custom control.
That works as well (even better) as the glowy button 100% skinned.
In most cases those things don't even look like buttons anymore,
and users *have to learn* that you can click on that glowy crap.
So no, I don't buy the "easyer for the user" story.
David Ching
>
>> They are designed for soccer moms who don't
>> know what LTR is and don't care.
>
> Moms speaking Arabic or Hebrew care about LTR.
>
Not necessarily the target audience.
>> if the only way they can do that is to put a
>> giant icon with "Burn an audio CD you can listen
>> to in your car" is the only way they can figure it out,
>> well... that is one audience for skinned apps.
>
> That kind of design is not what it takes for people to use something.
>
> That is the "Experience Designer" justifying it's salary.
> A *standard* button with an icon is not a custom control.
> That works as well (even better) as the glowy button 100% skinned.
>
> In most cases those things don't even look like buttons anymore,
> and users *have to learn* that you can click on that glowy crap.
> So no, I don't buy the "easyer for the user" story.
>
You and I don't have to buy it. I don't claim to like it or want to use it
myself. But I've seen with my own eyes that it's easier for some people to
grasp this kind of UI. That's the way it is, and since I like to get paid,
that's what I produce.
-- David
Joseph M. Newcomer
icon means. Microsoft doesn't ease this because each release of Windows uses some new,
cuter, more obscure icon, to represent common actions. There is nothing more apalling
than to be confronted with a collection of artistic objects whose meaning can only be
guessed at. Word 2007 is actually pretty good at making the interface nearly unusable in
this regard.
Having a button that says
"Burn an audio CD you can listen to in your car"
actually sounds like a very sensible button, a whole lot more useful than most obscure
icons.
None of this has anything to do with forcing controls to be in absolute positions on a
dialog.
I seriously detest iconic interfaces that have no popup tooltips or other help for the
visually impaired. A tiny icon is useless. A large bitmap has to be completely obvious
to the uninitiated. While it may be obvious to YOU that the cute icon YOU created means
"burn a CD that you can play in the car" it is probably not obvious to anyone else.
joe
On Sun, 22 Jun 2008 19:30:35 -0700, "Mihai N." <nmihai_y...@yahoo.com> wrote:
>
>> They are designed for soccer moms who don't
>> know what LTR is and don't care.
>
>Moms speaking Arabic or Hebrew care about LTR.
>
>
>> if the only way they can do that is to put a
>> giant icon with "Burn an audio CD you can listen
>> to in your car" is the only way they can figure it out,
>> well... that is one audience for skinned apps.
>
>That kind of design is not what it takes for people to use something.
>
>That is the "Experience Designer" justifying it's salary.
>A *standard* button with an icon is not a custom control.
>That works as well (even better) as the glowy button 100% skinned.
>
>In most cases those things don't even look like buttons anymore,
>and users *have to learn* that you can click on that glowy crap.
>So no, I don't buy the "easyer for the user" story.
David Ching
news:of7u541unjp0q586g...@4ax.com...
The idea of a skinned interface is to get away from tiny icons which are not
obvious and replace them with larger images that are more in your face and
self descriptive. For this to work effectively, sometimes a pixel alignment
is necessary, especially if a background bitmap is used. I know you put a
premium on respecting user's fonts and scrolling to fit available real
estate, but with all due respect, excessive scrolling is a poor UI, and
neither is it very pretty (which means soccer moms don't want to use your
app).
I am in the middle of this issue. I like resizeablity (and thus don't like
skinned apps), but also prettiness. Personally, I'm very glad to see next
generation UI's like WPF and Silverlight that bring the best of web UI's
(which are a whole lot prettier and make better use of real estate than
Windows apps, IMHO) to client apps. At the same time, they can remain
resizeable, by using advanced layout controls like Grid and Stack Panel (but
are not always so, as there is also a widely used Canvas control that puts
all children at fixed pixel offsets), and thus usable. Since there are
both resizeable and non-resizeable controls, it fits my experience that
there are cases for both.
My point is: for certain people, especially consumers, who are frankly dumb
beyond belief, the kind of UI that you think is really bad, is really very
good. To the extent that you hate skinned apps because you can't read the
text, these users hate standard apps because they can't figure out what to
do and have basically wasted their money. I can't see the point of one
group always berating the other one.
-- David
Mihai N.
> dumb
> beyond belief, the kind of UI that you think is really bad, is really very
> good. To the extent that you hate skinned apps because you can't read the
> text, these users hate standard apps because they can't figure out what to
> do and have basically wasted their money. I can't see the point of one
> group always berating the other one.
Not really bashing agains skinning in general.
But I can bet without looking that a skinned application brings nothing
to the user, and is just cute thing to make a graphic designer that ended
up as UI designer feel like he still does some "creative work".
And I will win the bet 9 out of 10 (if not more)
Thing is, there is tons of space for creativity in the UI design, only
not necesarily in the way things look, but in the ways they work.
Small touches, that you sometimes see in things like Outlook.
Click "To", start typing a name. You get close to what you want, press down-
arrow and you are in the list mivind down, no need of a tab. Press Enter,
the name is in the "To field" and the focus is on "Ok". Press Enter again,
all fine, dialog closed.
Just smart, non-standard use of focus.
I can paste a full path in an "File Open" dialog. But in 95% of the cases
opening the file actually fails if the path is enclosed in quotes, or if
there is an extra space at the beginning or end. Why? Is it so difficult to
strip the quotes and the spaces from the beginning and the end?
And why can't I just drag a file from Explorer in all standard applications
in order to open the file? I can do this in Word since forever.
Tons of opportunity for creative, *userful* UI design without glowy skins.
Now, one does what the client wants. No problem there.
Mihai N.
> to the user, and is just cute thing to make a graphic designer that ended
> up as UI designer feel like he still does some "creative work".
> And I will win the bet 9 out of 10 (if not more)
Some examples.
I find this:
http://common.packardbell.com/itemnr/instr_createcdfromiso/nero66_express.jpg
and this
http://techgage.com/viewimg/?img=/reviews/software/nero/nero8ultra/nero_8_ult
ra_04.png&desc=Nero%208%20Ultra%20Edition
way more clear than this:
http://www.dvdburner.info/images/nero-6-ultra.jpg
or this:
http://www.dvdshrinknow.com/images/scr_Nero_StartSmart_AltConfigure_bg.jpg.jp
g
Why is a round glowy button with two people better than a gray square button
with two people? Why is a question-mark with green laurels more clear than a
question mark?
In both cases, the more clear dialogs use standard (or close to standard)
controls.
How is this:
http://www.atpm.com/7.07/images/t-toast-window.gif
worse than this:
http://motogrrl.com/replayTV/images/dvd-toast.jpg
except for a designer justifying his salary?
Why are the round buttons or the tabs here
http://www.dcsoft.com/images/airgo_gcu_ss.gif
more clear for the user than the standard, square buttons or tabs?
(especially since none of the custom controls don't seem to make it clear
which one has the focus)
The only situation that probably justifiues skinning is imitating a real
object (if the imitation is really good).
If I am programming a TV remote, it ok and natural if the thing on screen
looks exactly like the real thing.
David Ching
(which is the focus of this thread). You even seem to like some of them.
But the issue is, if a skin does not allow resizing to allow child controls
to be placed with pixel accuracy, is it worth it? You seem to think not,
but mainly because you just don't like the skin or can't see why various
graphic elements were chosen. That is highly subjective.
I've heard 2 reasons for non-resizable skins, over and over: 1) Good
looking skins make people want to use the product, and thus sell it; 2) Good
looking skins allow more freedom to guide the user (who is targeted as not
knowing Windows, for example, they don't know to right click to get a
context menu, don't know to press the Space bar to click the focused button,
will ignore anything smalller than 18 point type, etc.) And if
implementing a skin is easier if you forgo resizing (of course it is), then
it will be tossed simply because it does not impact #1 or #2. Heck, the
target user doesn't resize a window even if it allows it. How many times
have you seen someone type in a little Outlook Mail window because they are
too dumb to drag it bigger?
Personally, I agree with you and want a high priority on resizeability
(which improves usability for intermediate to advanced people). But if I'm
building a product for someone who won't resize anyway, well, my personal
values on the resizeability/skin issues just don't make one whit of
difference.
Thanks,
David
"Mihai N." <nmihai_y...@yahoo.com> wrote in message
news:Xns9AC7F003...@207.46.248.16...
Joseph M. Newcomer
"not reallly common" it was "nonexistent".
There are times when you need pixels and not DBUs, such as when an image has to be placed
on a dialog, or a dialog has to be sized to a window. Fortunately,
MoveWindow/SetWindowPos are available to handle this fairly unusual set of cases.
Complaining that DBUs don't work ignores the fact that pixels don't work, either. In most
cases, pixels are precisely the WRONG approach; only in a few very rare cases do they
matter. I often work in a "blended" world where I do the initial layout using the dialog
editor, and the only time I ever look at DBUs is to get controls aligned when I have to
have two controls centered under a third, or something else fairly obscure. The rest of
the time, I just ignore the concept entirely. I certainly never care about DBUs at
runtime, under any circumstances.
joe
Joseph M. Newcomer
it nearly impossible to live in a world where the font sizes are not under the end user's
control. In CE, in particular, the use of the FlySpeck 3 font is the way most programmers
deal with the lack of screen real estate.
joe
On Fri, 20 Jun 2008 09:34:41 -0700, Henryk Birecki <soarin...@sbcglobal.net> wrote:
>I also have many dialogs in a WinCE application. I think you "hit the
>nail on the head with 'If user change de display settings "DPI" ' this
>is exactly why dialogs are specified in font units rather than pixels.
>If a user changes DPI, dialog size stays the same. You should scale
>your bitmap according to the DPI settings. Do you expect DPI change
>during program operation, while one of the dialogs is displayed?
>
>As to relationship between pixels and font units, I just experimented
>a bit to get it right for the font size I am using.
>
>Cheers,
>Henryk Birecki
>
>Erakis <Era...@discussions.microsoft.com> wrote:
>
>>Hi, I'm programming an application for Windows CE.
>>
>>I have to draw/set a bitmap as background of my dialog.
>>
>>This is like a skinned application. For that, I need to set the dialog size
>>to 340x234 "pixels" and not"Base unit" like resource do.
>>
>>Also I will have to add others components on this dialog like
>>(Button,TextBox, Label, ListBox, etc...) at a specified position in pixels
>>sothat they fit on the background image.
>>
>>If user change de display settings "DPI", the dialog size will changeand I
>>don't want that ! Because the position/dimension of bitmaps onmy dialog will
>>no longer fit.
>>
>>Is someone have any clues/suggestion to help me with that problem ?
>>
>>Regards,
Joseph M. Newcomer
Even in CE, it isn't a viable approach. Each of my three (dead) palmtops uses a different
screen size in pixels. [I can't get one to last two years, so I gave up using them. They
all come with one-year warranties, and I think that's for a good reason]
I already related the story where a client had a fancy bitmap background designed for
640x480 and didn't work at all well in 800x600. I actually spend a fair amount of effort
building resizable dialogs if there is any kind of display (listbox, list control, bitmap,
etc.) so the user can maximize the amount of information displayed. This applies to
dialog-based apps, modal dialogs and modeless dialogs.
joe
On Fri, 20 Jun 2008 22:28:23 -0700, "Mihai N." <nmihai_y...@yahoo.com> wrote:
>> Hi, I'm programming an application for Windows CE.
>>
>> I have to draw/set a bitmap as background of my dialog.
>>
>> This is like a skinned application. For that, I need to set the dialog size
>> to 340x234 "pixels" and not"Base unit" like resource do.
>
>I would not use such an application.
>It will waste most of my 640x480 screen.
>
>Having fixed pixel size dialogs is really bad user experience.
Mihai N.
No, don't like them. Some of them are barely acceptable.
It looks like less skin makes them more usable.
> But the issue is, if a skin does not allow resizing to allow child controls
> to be placed with pixel accuracy, is it worth it? You seem to think not,
> but mainly because you just don't like the skin or can't see why various
> graphic elements were chosen. That is highly subjective.
The point I was trying to make is that the skin does not bring any extra
help to the regular user. A gelly round button with no text and a stupid
icon is no more helpfull than a rectangular gray button with a stupid icon.
An what I have against skins by default is no only resizing,
but bad accessibility, bad internationalization, lost functionality,
the fact that they totaly ignore my font and color preferences in
control panel.
Again, not saying there are no good uses for skins.
But I have only seen very-very few.
To your arguments:
> Good
> looking skins make people want to use the product, and thus sell it;
Cannot argue this one.
> 2) Good
> looking skins allow more freedom to guide the user (who is targeted as not
> knowing Windows, for example, they don't know to right click to get a
> context menu, don't know to press the Space bar to click the focused
> button, will ignore anything smalller than 18 point type, etc.)
This is only potentially true.
In reality I have seen very-very few cases where skins help the user.
In most cases they only give more freedom to the designer.
I have yet to see a skinning example that works without being a good
imitation of a real object.
Now, I will try and stop here.
As a programmer I see very few cases where skins help.
Custom controls are really-really hard to get right.
And the work does not pay off.
Now, the one paying might want skins really bad.
And if the pay is good, it's ok, one has to pay the bills.
But I am not going to drink the cool aid and claim they are useful.
David Ching
> The point I was trying to make is that the skin does not bring any extra
> help to the regular user. A gelly round button with no text and a stupid
> icon is no more helpfull than a rectangular gray button with a stupid
> icon.
>
Agreed. But the jelly round button does fit into the style of the rest of
the skin, which allows bigger fonts, more color, hovering behavior allowing
for extra descriptions to appear on the skin, etc. And all that gives the
skin more functionality than standard Windows.
> An what I have against skins by default is no only resizing,
> but bad accessibility, bad internationalization, lost functionality,
> the fact that they totaly ignore my font and color preferences in
> control panel.
>
Yes, and those disadvantages must be prioritized. My point is the target
audience does not seem ot care about any of that (except localization, and I
explained you how my skins have better localization than standard).
> Now, I will try and stop here.
> As a programmer I see very few cases where skins help.
> Custom controls are really-really hard to get right.
> And the work does not pay off.
>
> Now, the one paying might want skins really bad.
> And if the pay is good, it's ok, one has to pay the bills.
> But I am not going to drink the cool aid and claim they are useful.
>
Probably you are right that the advantage of skins is 90% designer and 10%
user, but if the app is mass deployed, that is still a little help to a lot
of people.
-- David
Mihai N.
> user, but if the app is mass deployed, that is still a little help to a lot
> of people.
That was not my point :-)
It is not that a skin help the user with about 10%
It was that 90% of the skinks don't help the user in any way,
and very often harm, and maybe 10% help the user a little bit.
Tom Serface
have more character than a typical program. There are lots of things that
fall into this category (games, audio programs, video viewers, specialized
data viewers, etc.) I think many users enjoy the specialized experience.
Guys like you and me do not so much because we'd rather just get the work
done, but, for example, my kids are always enamored with cool user
interface.
Tom
"Mihai N." <nmihai_y...@yahoo.com> wrote in message
news:Xns9AC9D157...@207.46.248.16...
Joseph M. Newcomer
It is designed for 800x600, and MAKES SURE it will be full-screen by CHANGING my
resolution (it never occurred to the nitwits that wrote this that screen resolution is NOT
something a programmer EVER has the right to change!) So it has the wrong resolution for
my 1920x1200 screen, and it does horrible things to a multimonitor system; I have to turn
the second monitor off entirely because it goes into some "bad sync" state. It can't be
used on the second monitor at all. It is definitely one of the Best Possible Examples Of
The Worst Possible Way To Write An Interface I have seen in quite a while.
All because they wanted it to look cute, and be full screen.
The obnoxious people won't even tell the interface to their device so someone who
understands interfaces can write a decent one.
One of my projects is to use an APISPY-like capability to intercept the
screen-resolution-change commands and destroy them. An alternative is to use FileMon to
reverse-engineer the interface to the device. As soon as I get some time for hobbies...
joe
Tom Serface
I think there is a difference between modifying someone's screen resolution
for the sake of an application and having an smaller window on the screen
that is a fixed size and skinned. Many skinned applications (like WMP) have
a way to minimize or a smaller/larger version to give the user multiple
display options. I agree that changing the screen resolution is a really
bad idea.
Tom
"Joseph M. Newcomer" <newc...@flounder.com> wrote in message
news:9ei66458kec3ne3tl...@4ax.com...
Joseph M. Newcomer
is sufficiently irresponsible that "nitwit" is the printable polite term that can describe
them. This is actively a powerfully user-hostile act.
In my essay "Who owns the GUI", I should add a section on never changing the screen
resolution, but it never occurred to me that anyone could act so irresponsibly.
Note that skinning, although I think it is terminally cute, is rarely overtly
user-hostile. It's just a waste of programming talent most of the time. Perhaps all of
the time. But there are some things which must never be done:
using any Windows directory to hold any kind of non-DLL file
and it is rarely valid to put a DLL in it, unless it is a
DLL shared across multiple applications; it is essentially
never valid to put a per-application DLL in any Windows
directory
modifying PATH
modifying HKLM from the program
modifyng the clipboard except as a response to a Copy or Cut operation
invoked by the user
changing any system parameter, such as screen resolution, without
permission of the user
writing anything to the executable directory
joe
James Juno
application that saves some per-user settings. To avoid registry cruft,
I'm persisting them to an XML file which currently in the executable
directory. What location is better? It's a nonsensical (from the
user's standpoint) XML file, so the user's \My Documents location also
strikes me as an intrusion.
Thanks,
JJ
Tom Serface
parameters and I think it is common enough to have registry location for an
application. I think storing the file in the executable directory may
become problematic on Vista if the user is not an administrator and the
program folder is not accessible. You may want to put the settings in a
data folder under the user's documents. I tend to use the registry under
HKCU.
Tom
"James Juno" <j...@asteroid.fake> wrote in message
news:7_OdnQDgOI32W_7V...@scnresearch.com...
![Doug Harrison [MVP]'s profile photo](http://lh3.googleusercontent.com/a-/ALV-UjVvzhOQGbT9K0Re6Qg-OU4VGuHq0tAdTu01YlmIjUGm6t_o8g=s40-c)
Doug Harrison [MVP]
>Solid points. As an aside, I do have a question. I'm working on an
>application that saves some per-user settings. To avoid registry cruft,
>I'm persisting them to an XML file which currently in the executable
>directory. What location is better? It's a nonsensical (from the
>user's standpoint) XML file, so the user's \My Documents location also
>strikes me as an intrusion.
The executable folder is a bad idea due to implications on permissions and
won't work at all in Vista. I've had to play games with symbolic links to
deal with legacy programs in Vista. The AppData folder would be appropriate
for your settings file:
Chapter 4: Data and Settings Management
http://msdn.microsoft.com/en-us/library/ms995853.aspx
However, note that AppData is a hidden folder, and users who think they can
back up their data by backing up "My Documents" will fail to back up
AppData. Some programs store incredibly important data in the hidden
AppData folder; for example, Outlook stores .pst files there. So there's a
definite tension between hiding files the user does not deal with in an
overt way that also happen to be his crucial data. I guess the answer is
ultimately for users to realize that "My Documents" isn't the only place
"their data" is stored.
--
Doug Harrison
Visual C++ MVP
Joseph M. Newcomer
On Thu, 26 Jun 2008 09:40:10 -0700, James Juno <j...@asteroid.fake> wrote:
>Solid points. As an aside, I do have a question. I'm working on an
>application that saves some per-user settings. To avoid registry cruft,
>I'm persisting them to an XML file which currently in the executable
>directory. What location is better? It's a nonsensical (from the
>user's standpoint) XML file, so the user's \My Documents location also
>strikes me as an intrusion.
*****
If you store it in the executable directory
It affects all users
It won't work in most of the Real World
The latter is because in most large organizations, Program Files is write-protected (this
is the default in Vista), but this has been true since Win2K in many organizations (a
virus-attack-reduction strategy).
Use the AppData folder; see my SHGetFolder Explorer to find it. This is less intrusive
than My Documents and it is user-specific. It is also guaranteed to be writeable.
joe
James Juno
appreciated.
Joseph M. Newcomer
to the latest standards I've seen, a program must be robust and assume that any key inthe
registry can be removed at any time, arbitrarily, including the entire subtree for the
application. The rule was that "no program shall have its installer create registry
entries that cannot be re-created by the execution of the program" or some such phrase.
In one program I had, we needed to have the path to the DLL for an explicit LoadLibrary
call. This was because we were sharing a DLL with a third-party application. I had a
cached copy in the Registry, and the recovery process went like this:
Use the Registry key value
If that fails, check to see if the product is installed
If the product is installed, try loading from its execution directory
If that fails, prompt the user
Unable to locate the required
"c:\...full path here...\whatever.dll"
Do you want to search for it
[Yes] [No]
If the user selects Yes, pop up a file-open box
If the user selects No, abort the command that needed the DLL
That is, the program was prepared to re-create its entire Registry key from the ground up,
for any value. Those values which represented user options were easy; there were many
options dialogs available. But those that could not be represented by an explicit dialog
had recovery dialogs like the one above.
Obviously this does not work for .pst files and other such critical files, but for
configuration data, you have to assume at any point that the file has been deleted and be
prepared to reconstruct it.
joe
Doug Harrison [MVP]
Yep, that's good common sense. My registry "read" functions all take
default arguments and return them when the registry value is missing, and
the "save settings" functions recreate the registry hierarchy as necessary.
Joseph M. Newcomer
Read the Registry from HKCU
if that fails, read the Registry from HKLM
if that fails, use the hardwired default
This allows the sysadmin to set up "standard defaults" during installation but allows the
user to override them.
My Registry classes, for example, have options like
RegistryInt whatever(IDS_REGISTRY_WHATEVER);
whatever.load(0);
where 0 is the default value to be used.
joe
Mihai N.
> and it is rarely valid to put a DLL in it, unless it is a
> DLL shared across multiple applications; it is essentially
> never valid to put a per-application DLL in any Windows
> directory
I would go even further: nobody should write anything in any Windows
directory. The only stuff there should be MS files, (deployed using
the official redistributable packages), and drivers.
All proprietary files shared between applications belong in
"C:\Program Files\Common Files\<CompanyName>\<SharedComponentName>"
(of course, must use SHGetFolderPath and family :-)
Joseph M. Newcomer
egregiously bad one is the otherwise fine graphing package from GigaSoft, which dumps TONS
of completely irrelevant stuff into the Windows directory, and this is COMPLETELY
inappropriate. They even put their DOCUMENTATION in the Windows directory, which is
inexcusable!
joe
On Fri, 27 Jun 2008 22:48:34 -0700, "Mihai N." <nmihai_y...@yahoo.com> wrote:
>> using any Windows directory to hold any kind of non-DLL file
>> and it is rarely valid to put a DLL in it, unless it is a
>> DLL shared across multiple applications; it is essentially
>> never valid to put a per-application DLL in any Windows
>> directory
>
>I would go even further: nobody should write anything in any Windows
>directory. The only stuff there should be MS files, (deployed using
>the official redistributable packages), and drivers.
>
>All proprietary files shared between applications belong in
>"C:\Program Files\Common Files\<CompanyName>\<SharedComponentName>"
>(of course, must use SHGetFolderPath and family :-)
Joseph M. Newcomer
the DLL in the executable directory, you're better off doing an explicit LoadLibrary from
a known path than trying to modify the PATH variable. Modifying the PATH variable is an
invitation to catastrophic failure and long, involved, and consequently expensive tech
support calls. A little effort spent up front making your product robust is paid for
quickly by the reduced tech support"
This means that if LoadLibrary fails, it should also, as I indicated earlier, pop up a
dialog box that lets you find it and creates a Registry key for it.
Tech support is, for small companies, the dominant cost. I know. I spent 5 hours on the
phone to Sweden in the era before flat-rate international calling; we had a
several-hundred-dollar phone bill, and five hours of my very expensive time on top of
that. That call cost us on the order of $1000 for a $300 product (but the user was a
high-profile individual and we wanted to give first-rate support)
Don't depend on PATH, and don't depend on the windows directory.
(My classic example is util.dll, which everyone seems to have one of. All those little
utility functions. Echh!)
joe
On Fri, 27 Jun 2008 22:48:34 -0700, "Mihai N." <nmihai_y...@yahoo.com> wrote:
>> using any Windows directory to hold any kind of non-DLL file
>> and it is rarely valid to put a DLL in it, unless it is a
>> DLL shared across multiple applications; it is essentially
>> never valid to put a per-application DLL in any Windows
>> directory
>
>I would go even further: nobody should write anything in any Windows
>directory. The only stuff there should be MS files, (deployed using
>the official redistributable packages), and drivers.
>
>All proprietary files shared between applications belong in
>"C:\Program Files\Common Files\<CompanyName>\<SharedComponentName>"
>(of course, must use SHGetFolderPath and family :-)