Christian Studer 2017-11-08 03:42
UltraMon 3.4.0 is now available for download. New in this release is improved support for Windows 10 as well as several bug fixes, see the release notes for more information. This is a free upgrade if you have a version 3 license.
Christian Studer - www.realtimesoft.com
|
xsvtoys 2017-11-09 07:38
Got it, works great. Thanks for keeping UltraMon going, still using it every day after 15 years!
|
Christian Studer 2017-11-09 08:28
Glad to hear that! Was surprised myself when I saw the updated About dialog and realized that UltraMon is now 18 years old.
Christian Studer - www.realtimesoft.com
|
Tom R 2017-11-09 12:44
Post install the application will not launch w/o crashing. If I remove it to back out will I lose my settings? I submitted this already to @support.realtimesoft.com but have not had a reply. Please help! I love this app but now it's dead for me.
|
Lionel 2017-11-09 16:32
Installed 3.4 over 3.3, rebooted with primay and secondary monitors enabled. All seemed well. Then I enabled 3rd monitor, the wallpaper was a combination of that for monitors 1 & 2, even though the correct wallpaper was shown in the UM wallpaper selection window (I have a different pic for each monitor.) A second reboot of the system with monitor #3 enabled has fixed that minor problem. Otherwise, all seems well.
|
Lionel 2017-11-09 16:35
Posted above before adding that I am running Windows 10 Pro Insider build 17035
|
Daniel Beardsmore 2017-11-10 01:38
I don't do reboots, but I'm just curious if a reboot is actually required for this update. I started UltraMon manually and it's working, but the main thing I notice is that the colour matching for the extra title bar buttons is wonderfully erratic.
In particular, sometimes for a new window they appear white (instead of black), windows shown when pointing to a taskbar thumbnail have only UltraMon buttons or (if they are minimised) no title bar buttons at all, and when you focus a window with Active Window Tracking (AKA XMouse) the UltraMon title bar buttons appear not to get redrawn and remain in the inactive title bar colour (there should be a hook to detect focus set by Active Window Tracking). I notice with PuTTY that the colour is stuck in the active colour instead.
Maybe I need to reboot to fix the colour calculations, but that seems a bit unlikely somehow.
|
Christian Studer 2017-11-10 03:01
Daniel, a reboot isn't strictly necessary, but you'll need to sign out, otherwise the hook DLL from the previous release will still be loaded in already running processes.
Tom's issue is related to the version of Windows 10 he's using, what I already know is that version 1507 and 1511 won't work, I'll test with 1607 next and will report back. If you're using 1703 or 1709 you'll be fine.
Christian Studer - www.realtimesoft.com
|
Christian Studer 2017-11-10 04:54
I have now tested with Windows 10 version 1607, works fine with 3.4.0.
Christian Studer - www.realtimesoft.com
|
Daniel Beardsmore 2017-11-10 06:49
UltraMon did get closed by the MSI, and all the window decorations disappeared — I guess you're suggesting that the hook DLL remains loaded even when UltraMon exits? Fresh processes and old processes are affected alike.
The main problem is that it's not detecting when a window is focused by Active Window Tracking: if I point to a window, it gets focused, but the UltraMon title bar buttons don't change colour until I physically click into the window. If I use alt+tab to switch window, the UltraMon title bar buttons work fine.
I never noticed this before as it doesn't apply to XP, and I've had XP buttons in Windows 10 all this time. Now that I have native buttons in UltraMon, I can see the bug.
It may be a very old bug, that would have shown up in Windows 8, but I jumped from XP to 10!
|
Bill 2017-11-10 09:29
Very happy to see this new update indicating there is still interest in UltraMon.
Thanks for keeping this great utility alive!
|
Christian Studer 2017-11-10 10:32
Thanks Bill, glad to hear you like it.
Daniel, I have now tested with active window tracking, but so far haven't seen the issue, the window buttons change to the correct color when hovering over an inactive window to activate it.
Active window tracking was enabled via Control Panel > Ease of Access Center > Make the mouse easier to use, option 'Activate a window by hovering over it with the mouse'. I tested on 64-bit Windows 10 version 1709.
Christian Studer - www.realtimesoft.com
|
Luiz 2017-11-10 10:55
Hi Christian,
Great to see you maintaining the program and the new version of UltraMon. Love ths program as I run 4 21" monitors on my desk and it is awesome.
Wanted ot let you know about a couple of issues you may want to looking into. with some of the latest version programs, UltraMon buttons on the top right as being superimposed on the program's buttons making it difficult and in some cases impossible to minimize, resize or close the program as the UM buttons are sitting on top of it.
Running Windows 10 version 1703 OS Build 15063.674
I've got some screen shots if you would like to see. ping me at my address and I'll return with the images and programs.
Thanks much for keeping up with the program.
Luiz
|
Christian Studer 2017-11-10 13:51
Thanks Luiz. To fix the issue with the window buttons, go to UltraMon Options > Compatibility, then configure settings for the affected application and set the custom button spacing option, I would start with 50 pixels and adjust if necessary.
Christian Studer - www.realtimesoft.com
|
Luiz 2017-11-10 16:55
Thanks Christian.
Unfortunately they are not all on the same place. I use 12-15 different software packages and they each show in a different location. In some cases the there are different versions and the buttons display in different location
Do I have to do this for each one? Isn't there a fix for that? :-)
If not, I may just have to turn it off which is disappointing as I tend to go multiple screens with spreadsheets and that feature alone is awesome.
Thanks,
Luiz
|
Christian Studer 2017-11-11 02:58
Unfortunately there's no way around this, you would need to set up compatibility settings for each affected application.
The problem is that some applications don't report the position of their window buttons at all, other applications report invalid positions (for example Office 2016). UltraMon does try to detect window buttons via other means as well, but this doesn't work with all applications.
Christian Studer - www.realtimesoft.com
|
Lionel 2017-11-11 13:30
The UM move and maximize buttons appear correctly in Firefox 56.0.2, (with default positioning) but are superimposed on the close and maximize buttons in Firefox Developer Edition 57.0b14. Setting a custom spacing for FF Dev Ed (130 pixels looks fine) but it also affects 56.0.2.
64 bit Firefox (both versions) on 64 bit Windows 10 Pro Insider Preview Build 17035.1000
|
Christian Studer 2017-11-12 03:52
Lionel, to fix this delete your existing compatibility settings for Firefox, then create new ones for the developer edition and check the option 'use full path' (on the Select Application screen), this way the settings will only get applied to this version of Firefox.
Christian Studer - www.realtimesoft.com
|
Daniel Beardsmore 2017-11-13 03:16
For Active Window Tracking, I use Winaero Tweaker to configure it, to enable a 300 ms delay and to disable auto-raise. The compatibility problem with UltraMon comes from having auto-raise off. (The ability to disable auto-raise is a long-standing hidden setting that used to be in TweakUI in XP days.)
There are still programs that trick UltraMon into drawing white buttons instead of black buttons when active (e.g. Winaero Tweaker itself) or pale black buttons instead of pale white buttons when inactive (e.g. PuTTY, PDF-XChange Editor).
These are programs that appear to use native title bars, and if I disable Active Window tracking entirely and then restart Winaero Tweaker (the restart is required), the problem goes away, so my best guess is that it's something to do with tracking the window active state fully. UltraMon can track the active state, but it's not detecting the change of caption buttons from black (active title bar colour) to pale white (inactive title bar colour).
|
Daniel Beardsmore 2017-11-13 05:32
OK, it's not program specific -- the fault has now moved from the existing PuTTY window to an existing JujuEdit window.
My guess is that the use of Active Window Tracking is somehow causing the program to misread the details on the colour of the title bar widgets. Sometimes they get stuck in one colour (active or inactive) or sometimes they are reversed (active drawn in inactive colour, and inactive drawn in active colour).
It may relate to the need to physically click into the window to force the extra title bar buttons to redraw, which I assume comes from having auto-raise disabled. (The reason for turning off auto-raise, by the way, is to be able to move the cursor between monitors, without a background window being forced to the top above a smaller window that I was aiming for; auto-raise is messy, especially if you can't control the delay.)
I suspect that this is nothing to do with Windows 10, but merely the fact it's the first time I've ever seen post-XP buttons (as I jumped from XP to 10, and 10 was getting XP buttons until 3.4).
|
Christian Studer 2017-11-13 11:14
Daniel, I've been able to reproduce the issue when using active window tracking without auto-raise, will look into this.
Regarding PuTTY: do you have the issue also if active window tracking is disabled? For me this works fine, I tested with version 0.70.
Christian Studer - www.realtimesoft.com
|
Daniel Beardsmore 2017-11-14 11:13
I thought it was program-specific, but it's not. Sometimes the active/inactive state of UltraMon's title bar widgets get flipped (I assume due to Active Window Tracking) and PuTTY at that point was an affected window.
Active Window Tracking support in Windows is improving — I'm curious to see if Outlook 2016 finally copes with it (2013 doesn't like it). Tooltips tend to foul it if you set the mouse wheel to scroll the window under the cursor, as Windows will focus the tooltip by mistake :P
It's a great idea, but so few people use it that it leads to all sorts of bugs :(
|
Jernej Simončič 2017-11-17 16:38
I noticed a small problem with titlebar buttons, specifically when I invoke file Properties window from programs that aren't high-DPI aware (I'm using a high-DPI monitor and running Windows 10 at 250%).
If the application is manifested to support XP themes, the button to move the window to another monitor is double-sized and covers the Close button. If the program isn't manifested for theme support, the Move button just covers the Close button.
This doesn't happen when invoking Properties from a high-DPI-aware program, such as Explorer - the button has the correct size and placement there.
|
Christian Studer 2017-11-18 15:16
Jernej, can you send me the application you used for testing? I'm seeing the issue as well, but am getting quite different results, here's a screenshot from an app without DpiAware and CommonControls manifest. This is on Windows 10 version 1709 with 3 monitors all set to 125% DPI.
Christian Studer - www.realtimesoft.com
|
Jernej Simončič 2017-11-19 02:23
For theme-aware application I used FAR Manager (it's a console application, to get to Properties press F11 -> EMenu), and for non-theme-aware WinDirStat.
|
Jernej Simončič 2017-11-19 02:39
Oh, and I forgot to mention, I'm using a high-contrast theme (with customized colours), which may affect the behaviour (one thing that differs is that theme awareness is ignored if the application isn't also manifested to support Windows 8).
|
Jernej Simončič 2017-11-19 15:15
More problems with buttons:
- too small in multiple programs: Office 2016, Corel Paint Shop Pro (multiple versions)
- nearly invisible (but functional) in UWP apps
- they don't appear at all in Vivaldi browser, RoyalTS (at least in non-DPI-aware mode), Daemon Tools Ultra, Discord, Steam and various GTK+3 programs (you can use my compile of glabels for testing)
I like the new design of titlebar buttons, and I think that it should be used even with non-themed programs, since the minimize/maximize/close buttons are always flat.
|
Christian Studer 2017-11-20 03:15
I have now tested with the applications you're using and a high contrast theme, will look into this but am not sure if there's a fix.
Christian Studer - www.realtimesoft.com
|
Christian Studer 2017-11-20 03:18
Hadn't seen your most recent post when replying, those issues are likely related to the high contrast theme, I'll look into that as well.
Christian Studer - www.realtimesoft.com
|
