The calculator needs an "always on top"

[Bob I]

What if you put a humidifier and a dehumidifier in the same room?

That's called recycling! And the "greenies" would love you for doing it.

 

[VanguardLH]

That's OK until someone starts making suggestions to MSFT. Then it's
NOT OK.

Since the OP was asking for a user-configurable option or a title button
to do the same, why are you complaining. Do it how you want and the OP
can do it how they want. Both of you would be happy. Alas, Microsoft
doesn't provide such functionality (which would be adaptive per program
and even per process).

While most of the 3rd party utilities that I've seen to let you
configure a window to enable its always-on-top attribute, they run as a
tray icon. Like the OP, I would prefer an app that modifies the
titlebar object of every standard Windows window to add a titlebar
button. For example, this is how GentleSecurity for their GeSWall
security product adds their "G" button to the titlebar of the web
browser (or any app is has isolated) so you can choose to run it
non-isolated - if you want for that process instance. After all, it's
not like the realestate in the title is so valuable that you cannot
tolerate the space consumed by a button the same size as the "X"
titlebar button. If you're that desparate for titlebar space for the
window's title then configure your web browser to stop advertising
itself in the title (e.g., for IE, remove the "- Windows Internet
Explorer" blurb displayed in every one of its windows).

The OP won't get what he wants from Microsoft. It isn't an option
available in Windows 7. 3rd party utilities (window managers) can
compensate but not necessarily have the behavior or method to access
them that best matches each user's criteria.

You really think Microsoft is listening to feedback from one or even
many thousands of consumers that are purchasing *single* licenses of
their products? Dream on.

 

[Dave \Crash\ Dummy]

You're assuming always-on-top processes will cooperate with each
other. I've seen where a couple of always-on-top programs compete
with each other (regarding z-axis positioning) with the result of
constant flickering as each program yanks focus away from the other
always-on-top program making both programs unusable (and, as I
recall, consuming so much CPU despite for a minimal change of
property, like focus, that the computer because nearly unusable).

So why haven't you looked at 3rd party utilities to manage the window
attributes as you want? Like:

http://www.softpedia.com/dyn-search.php?search_term=always+on+top

I glanced at Always On Top, but decided to try FileBox eXtender,
instead. I had been using DeskPins, but it was awkward.
http://www.hyperionics.com/files/index.asp

 

[XS11E]

Since the OP was asking for a user-configurable option or a title
button to do the same, why are you complaining.

You answered that better than I can, see below:

Alas, Microsoft doesn't provide such functionality (which
would be adaptive per program and even per process).

And that's why. MSFT isn't going to re-write Windows for something so
silly.

The OP won't get what he wants from Microsoft.

Of course not and I'm glad of it.

You really think Microsoft is listening to feedback from one or
even many thousands of consumers that are purchasing *single*
licenses of their products? Dream on.

Actually, yes, they are. They're ignoring such feedback but if enough
people start asking for it, we're screwed.

 

[John Williamson]

Actually, yes, they are. They're ignoring such feedback but if enough
people start asking for it, we're screwed.

So, if someone asks for an *option* do do things in a way you don't
like, and M$ listen to them, that's bad?

 

[XS11E]

So, if someone asks for an *option* do do things in a way you
don't like, and M$ listen to them, that's bad?

No, if someone asks for an *option* to do things in an awkward,
inefficient way that requires a major re-rewrite, that's bad.

 

[VanguardLH]

No, if someone asks for an *option* to do things in an awkward,
inefficient way that requires a major re-rewrite, that's bad.

Adding a button to a window's title bar does not require a major rewrite
(presumably you meant the OS). Doesn't require any rewriting of the OS.
It would be handled by a separate window management process (as in the
example already provided regarding GeSWall).

Adding another parameter field to the Windows Explorer shell .lnk file
used for program shortcuts does not require a major rewrite of the OS,
only a modification of the common dialog that shows the properties to
add display of the new field. There are already lots of attributes of a
..lnk file that are not displayed in the common Properties dialog for a
link file. There are also 6 unused bits in the 32-bit LinkFlags
structure in a .lnk file, so these could be used for some purpose(s).
Adding a linking a visual object added to the common Properites dialog
to an unused flag now used for new purpose would be trivial; however, it
would not be backwards compatible unless the new dialog was migrated to
older versions of the OS via update.

A program that provides it own z-axis management (always on top) through
a configuration option or command-line switch requires absolutely no
rewriting of the OS at all. You thought a little code like below
constitutes a major rewrite?

http://www.codeguru.com/cpp/w-d/dislog/article.php/c1857/Making-a-Window-Always-On-Top.htm

It's just an attribute of the window that you can set in your program,
so you add a couple lines for setting the attribute (which is from the
Win32 API so it's available for all windows), add a new visual object in
your config UI dialog for the new option along with a couple more lines
of where you are going to save this config option and to read it when
the app or dialog opens. At some point, an app that paints a window is
going to call a function to do that or to position it so the window can
be attributed to be always on top as in the ONE line using HWND_TOPMOST
(perhaps already present in the existing program code) of:

SetWindowPos(myHandle, HWND_TOPMOST, 0, 0, 0, 0, SWP_NOMOVE|SWP_NOSIZE)

 

[Brian Gregory [UK]]

No, if someone asks for an *option* to do things in an awkward,
inefficient way that requires a major re-rewrite, that's bad.

Nothing needs re-writing.
Other programs like Task Manager already do exactly what he wants.
All that needs doing is adding a little extra code to the calculator.

 

[XS11E]

Adding a button to a window's title bar does not require a major
rewrite (presumably you meant the OS).

No, I meant to the calculator program which has been finished code for
many years.

 

[John Williamson]

No, I meant to the calculator program which has been finished code for
many years.

Assuming the source code is still available, (According to rumour, this
is not always a given where Windows is concerned) it just needs
recompiling with a different window option. If not, the Microsoft
Calculator is not exactly a major program, and a replacement is the sort
of thing they could give a student to work on as their team entry project.

Admittedly, I couldn't write it without a lot of head scratching, but
I'd bet my youngest brother could.

 

[VanguardLH]

Assuming the source code is still available, (According to rumour,
this is not always a given where Windows is concerned) it just needs
recompiling with a different window option. If not, the Microsoft
Calculator is not exactly a major program, and a replacement is the
sort of thing they could give a student to work on as their team
entry project.

In fact, Microsoft's developers, as a sideline as they did with XP
powertoys, could modify the Calculator Plus program to have the new
always-on-top function. Then just offer it as a download from their
site (microsoft.com/downloads). The standard (old) calc.exe program
would still be there and untouched so it behaves just like before and
cannot be made to behave differently; however, the new calcplus.exe
program could be modified anytime they want with each version having
newer and more functions.

 

[VanguardLH]

No, I meant to the calculator program which has been finished code for
many years.

That would still not be the major rewrite you claim. Eventually the
program has to make a call to create a handle to a window (i.e., open
the window which also assigns a handle ID to it). In that system API
call can likely be added the HWND_TOPMOST attribute. Yes, a recompile
would be needed but if the code was stable before then there should be
no compile-time errors, and since I'm talking about standard system
calls then there won't be any run-time errors, either.

Presumably Microsoft has its own code archived somewhere. If they don't
then they shouldn't be proliferating unsupportable programs. The change
would be trivial as would the compile and distributing the new calc.exe
file via Windows Updates. After all, if you recall, it was trivial for
Microsoft to modify browseui.dll back in SP-3 for Windows XP just to
remove the Address Bar (that many users had to figure a workaround to
return that feature).

It's not the big deal you profess. It would be one of the top ten most
trivial updates Microsoft has probably ever had. Even if Microsoft
didn't want to touch calc.exe, that doesn't preclude them from modifying
their calcplus.exe (Calculator Plus) powertoy - which they already
disclaim behavior or mainstream support (see my reply to John).

However, while we have focused on just one program getting updated to
add an always-on-top (z-axis) user-configuration feature (which can
easily be added to any program that opens a window), I believe the OP
was extending the argument to allow any window to have an always-on-top
feature. Having program keep itself on top is simple (but requires a
recompile - just like security updates, patches, fixes, and new features
in new versions would require a recompile). A system-wide window
manager that can make individual programs or just current processes
instances have their windows on top would require more work. Sorry, but
I'm not an OS programmer and don't know how Windows uses a global
windowing manager other than to note that most programs have code to
manipulate their own windows.

3rd party windowing managers (that monitor for open window handles and
modify their attributes) come in when you want a function to spread
across all windows and if they can do it then it's something that could
be built into the OS. The always-on-top utilities that I've seen are
rather tiny (>0.5MB no GUI, just hotkeys; 3.8MB with GUI resources) for
their memory footprint. Of course, if this functionality were embedded
into the Windows-integrated window manager and made available via
system-wide hotkeys and possibility add a titlebar button in each window
the memory footprint would be even smaller.

That the window manager (dwm.exe) in Windows Vista+ in non-replaceable
does not dictate that it cannot be updated by Microsoft. It's going to
get updated someday for security patches or bug fixes so the recompiles
are going to happen and that's when you slide in new functionality.
They already replaced the window manager from Windows XP when they went
to Vista with different functionality. Updating the window manager and
adding functionality to it is doable, it does not have to be a major
rewrite, but it's nothing Microsoft is focused on adding to Windows
probably because there are so many 3rd party tools that already provide
this functionality. At some point, Microsoft may even target some
software company for acquisition when it wants to include new or
different technology in its Windows product to give them a head start
rather than writing from scratch. In that case, I'd suspect the first
stab Microsoft would take would be to make the utility a service
configured to Auto start on Windows startup so they wouldn't even have
to update their window manager.