http://prntscr.com/dyz833 ?

Nah, good try, but that is actually how it is supposed to work - the moon will rotate and the calendar will shift to those days if you click on the little moons.

It's something else.

Haha, I really didn't realize this. But yes, now I remember that there was a setup window before.
Makes no big difference to me to be honest. But still appreciated!

it feels like nitpicking, but since you have put so much effort in the moon calendar i thought i might suggest this
the edge where the background loops sticks out
http://prnt.sc/dz2j5d
it would look better if you could blur the transition line on both sides

Backgrounds... reminds me of Easter eggs...

got something, but not of egg variety
if you open the moon calendar, then moon phase settings, and pres on the button in the settings to open the calendar, calendar and the settings close and the calendar opens again, but all modules docks and shelves are unclickable (and produce that annoying windows beep)

That's actually a bug in VB. Trying to come up with a way to work around that.

Here is what I found out so far: it only happens if the new window is set to be visible in the taskbar (i.e.; create a taskbar button).

For instance, you will get the same problem if you right click the Net Meter module, select Active Connections, right click the Net Meter module again, select Net Meter Settings and then click the Active Connections button.

The Net Meter Settings button disappears, even though it should not. Because it is a modal window, when you close the Active Connections window the application will hang because it thinks the Net Meter Settings is still visible to the user (but it's not).

However if you do the same thing but this time with the Net Statistics dialog, everything will work as it should. Why? Because the Net Statistics dialog is NOT set to show in the taskbar.

Oh this is nice.

So, Settings windows are always shown in Modal mode, i.e.; all other windows in the application are disabled and execution stops until the Modal window is closed. This is necessary because certain actions (such as saving changed settings) can only be performed by the application once the user has finished setting them in the Settings window and closed it, either with Cancel or Ok.

Now, the problem is that some of these Settings panels can also open other windows, which are not required to be Modal. Examples are the Active Connections and Net Statistics dialogs in Net Meter Settings and the Moon Calendar dialog in Moon Phase Settings, which can be left open at all times too and don't interfere with normal execution of the application.

HOWEVER, once a modal window or dialog is open, all subsequent windows can only be open as Modal windows as well. So, when the user clicks on the Moon Calendar button in the Moon Phase Settings dialog, the Moon Calendar opens as a Modal window.

So far so good.

The problem is when the user clicks that button but the Moon Calendar is already open as a non-Modal window. A non-modal window cannot appear above a modal window.

So, what I do is close the non-modal dialog and immediately open it again, but this time as a modal window. Works great...

... unless the window is set to show a button on the taskbar. That's when all hell breaks loose: VB gets confused and when the non modal window is unloaded/closed, the Modal window gets hidden too (if you try to hide that window instead of unloading it, you get an error saying that the Modal window needs to be closed first, so my guess is that Microsoft programmers did not take into account the fact that the form could be unloaded instead). Again, this only happens if the other window is set to show a button on the taskbar - if it isn't, everything is fine.

Now, once VB gets in this state, the application is permanently frozen for all intents and purposes: execution will not continue until the modal window is closed, but the user cannot close it because it is no longer visible.

I tried hiding the window via the API instead and what I got was even worse: this time the modal window did not disappear, instead the Moon Calendar window popped up *behind* the Moon Phase Settings dialog and *both* were disabled, so, again, no way to get out.

Fun fun... lets see what I can come up with.

Hmmm, looks like the only solution, given the alternative, is present an error message box to the user saying that dialog is already open.

can you add a check to the button to see if the requested window is already open?

Yes, that is what I wrote above.

I already tried every API trick I could think of, but the fact remains: to show that window on top of the settings dialog it must be closed first, and as soon as I do that VB also closes the settings dialog and gets into that confused state.

I think it actually corrupts the internal structure of the Settings dialog, since I can't get it to show again until I end the session.

So the only solution seems to be an error dialog stating that that window is already open. Don't like it, but it's better than the application freezing on you.

In other news, I was trying to throw in another goodie into the mix just before the final release, but alas, I failed miserably (can't win them all, I guess?)

This was related to the option that colorizes the theme with the dominant color of the current Windows wallpaper. The idea was to transition smoothly from the previous to the new color when the wallpaper changes, instead of switching abruptly to the new color as it happens now.

I tried it with a single dock and it was actually looking pretty good despite the fact that the transitions can/should not be linear (if they are and the two colors are too far apart, you get stuff like passing through green when going from red to blue, which is not exactly what you want).

Problem came when I added the Shelf and the Desktop Modules to the transition - performance dropped like a rock! Instead of a color switch every 30/50 ms (which made the whole color change very smooth when experimenting with a single dock), each cycle now took longer than 100 ms, which made the whole thing choppy and therefore defeated the purpose.

The real issue is that when you do a color change, currently absolutely everything needs to be re-calculated (blur regions, bitmap dominant colors, etc) and redrawn again (background bitmaps, icons, icon text in the Shelf, tabs, etc...) and neither the Shelf nor the Desktop Modules were ever optimized for full quick redraws.

Haven't completely given up on the idea, though, since I liked what I saw when I was experimenting with a single dock, but alas, it won't be for this release.

i missed that post

Argh, I give up... A small hint maybe?

You're already staring at it...