yereverluvinuncleber

Goodnight everyone! Goodbye from me to you and Deviantart!

We'll be seeing you...

This journal entry follows on from the RocketDock Enhanced Settings Screen Pt1 that you can find here: www.deviantart.com/yereverluvi…
It summarises the project I have been working on for the last year, ie. a replacement for Rocketdock.

-oOo-

Yes, I know it's mental.


Fig. 1 The first mock-up for my Mediaeval version (Right click to view full image, then you need to click on it again to see it full size and in full detail)

Note the above mock up it isn't 100% complete as some elements will need to be improved, resized, relocated or their allocated space increased, this is just a Mediaeval mock-up based upon my tool's original layout.

You aren't meant to like this design, it is just a rather extreme trial reskin. I was simply applying a Mediaeval-inspired theme to one of my programs to see how well a .NET program takes a real theme. I know a VB6 program can do it as I've done similar before. In the past I have just applied a simple classic high-contrast theme to both the VB6 version of the program and the .NET. Now though, it is time for a serious trial with theme-ing VB.NET.

This version may never reach an end user as it may be for my own personal use. I do understand that such an extreme theme has only a specific usage, for a mediaeval game or something similar (pronounced thomething thimilar). The idea was taken from an earlier re-skinning of mine.


Fig 02. File browser themed to a Mediaeval theme.

It says Steampunk there but it really means Mediaeval in that high Victorian style is decidedly gothic and hence from the middle ages. This was a skin from my javascript desktop media player.

This was all done in Photoshop and the good thing about creating a design in Photoshop is that in just one click I can have a fully working program running on my desktop as a RAD trial widget after about a mere minute of processing. All the separate graphical object elements are cut and extracted to PNGs and a widget created that can act as the basis for a VB6 or VB.NET design. It is a useful method of skinning a VB program that more should give a try.

-oOo-

As we all know the interfaces that Windows generally sports are extremely boring with a grey or white theme whilst the new versions display a uniform blue. As you can tell, some of my skins are far more adventurous and possibly quite a bit mad...

Regarding much more simple skinning, I have applied two skins that replicate both the default theme of Windows XPs classic theme and Win7's lighter default version. This is the older VB6 version running under Win10 with the default theme but customised with my own fonts &c. I call this the low contrast mode. For my eyes it is too uniform and too bright.


Fig 03. The tool in low-contrast mode (the default for Windows 10)

I prefer the default colours that XPs used to sport with the classic theme. Here below you can see it running with what looks like the XP look and feel, a look that I tend to call the high contrast theme. On Windows 7 you could still obtain the high contrast look by selecting the classic theme but Win10 no longer gives you that option. So, I have skinned it myself so that you can select it if you desire to. There is now an option in the right click menu to select the skin of your choice.


Fig 04. The tool in high-contrast mode on Windows 10

Note: this isn't really themeing as provided by the o/s but bespoke themeing in my own code. In that code, I change the colour of all the controls and then use previously prepared images for all the buttons. The 'bespoke' themeing is designed to give you a better look and feel in the more modern versions of Windows that are supplied without the classic theme. It is certainly better than the Win10's default colours but not perfect as you can see.

Unfortunately, there are some bugs I cannot workaround, the MS-supplied right hand scrollbar slider control has the default colour for Win10's lighter theme and cannot be changed whilst the left hand scroll bars on the 3rd-party supplied tree control successfully manages to match the darker theme. Regardless of the inconsistencies, this looks sufficiently XP-ish to make it familiar to someone transiting from the Win7 classic theme to Win10's 'modern' look and feel, which personally, I despise.

Regarding the bottom left size slider, it now allows me to colour it and this is because I am using a replacement control in place of the standard slider as provided by Microsoft in MSCOMCTL.OCX. This alternative slider has a backcolor property which allows it to take a colour successfully. The old MSCOM slider would offer the option of a runtime colour change but it would mistakenly only show the new colour only after the slider had been manually adjusted by the user's cursor. Until that time you were left with an ugly, partly mis-coloured bar.



VB6 has a problem in that all the essential little bits that form a typical program come from external DLLs.  If you want these 'extras' then these have to be included with your program in the form of files called OCXs. Without them your program will appear to lack functionality and therefore they are really not optional and in reality, essential. The problem is that each OCX needs to be bundled with your program and 'registered' in Windows using the command line. In addition, there could be conflicts with the OCXs you are providing and with those that are already registered with the version of Windows you are running. This problem is known to VB6 programmers as 'DLLHell'.



In order to get round this I am purging all the 'extra' functionality that is typically provided in the external Microsoft DLLs and migrating them to alternative methods. There is a VB6 developer named Krool that has been coming up with replacements for all these essential little bits, the various objects, treeviews, sliders, progress bars, tab strips &c that are used in a typical VB6 program and providing them as FOSS code. It is these modifications that I am currently incorporating into my program as code.

It means that a user will be able to run my enhanced icon settings program without having to do any extra work registering external dependencies. The program will just 'run' by itself. That's obviously the way it should be.

These new controls are rather impressive. I was initially reticent to use them as they came in a bundle of controls all bound together. I wanted no complicated dependencies in my program so, I separated them out so they are easier to debug. I am using just two of the alternatives here, the slider and the treeview.

The slider was a straight drop-in replacement, the treeview wasn't, requiring a little more jiggery-pokery to get it to function as per the older MS control. One thing Krool's controls require is a user-guide for each control. There is that installation/configuration document that was created by a user but I find it tends to put people off, being a little confusing and rather long-winded.



The end result of the styling exercise on the XP version? The images don't do the change justice but the high-contrast theme looks much better on the desktop than the default themes provided by the o/s.


Fig 05. The tool running on the Windows 10 desktop in high-contrast mode.

I now have a menu option that allows the user to switch to a "high contrast theme" at any time. I will include this with any other VB6 app that I create from this point on. I need to complete the .NET version styling now but more on that later.

For the moment, the Rocketdock Enhanced Settings tool has been made available to download here:
sourceforge.net/projects/rocke…

DO NOT FORGET - this thing is still BETA, it isn't ready yet and so bugs will show their heads! Regular updates will come.

For the moment a mere zipfile that you need to download and a readme.txt which you need to read... I will do a little more testing and update with any bugfixes but I think the damn thing actually works...That's a milestone for me, so many small bugs have delayed release. I'm glad to get the thing out.

Recent changes include enabling HOME/END and PG UP/DOWN on the rocketdock icon map and the automatic gaining of focus on the icon map as soon as it appears allowing a keypress to register.

I have discovered a bug regarding creation of new icons at the end of the icon map - need to fix that
and my recent improvements  to the VB6 version need to be carried over to the VB.NET version

I have created the second part of the Rocketdock trio, the Dock Settings utility. This is the tool that Punklabs created to configure the dock itself rather than the icons. This tool appears to be a lot more simple to program than the Icon settings tools but has proven to have its own issues to resolve. The various  dialog boxes that are used to choose fonts and colours are never easy to implement using VB6 and as I am trying to create  executables that require no external dependencies it is all the more tricky. In addition, Windows 7+ has a feature that causes problems with some corruption of data. Windows controls access to the registry just like it controls access to files. If you try to access the registry entries of another program then Windows presents you with a 'shadow' copy that you can view and even change but it does not affect the original location. This is a really useless method of implementing security, allowing you to make changes but never telling you that the changes you made will have no lasting effect whatsoever to the real data. A typical Microsoft bodge. Imagine saving your changes to a Word document but Windows ignoring you and deciding not to save your changes? That is the equivalent level of incompetence but this actually happens at the registry level.

The result is that not only does windows try to prevent you from doing what we want to do, it also on occasion seems to corrupt the data. I have yet to determine exactly how and when but data corruption is the result. So, to get around this balderdash my utility must run as administrator. This is no real problem as many dock type programs that need to operate with system resources often require administrator access. I wanted to avoid it having admin. access by default but it now seems impractical.

So, even this small utility has presented its challenges. However, it is now complete 99.9%, barring a few bugs and a couple of improvements.



It isn't quite as pretty as the other enhanced icon settings utility but it is prettier than the original Rocketdock version, it functions in all respects and so, it'll do.

Recent changes include:
o Fixed a bug with selecting the blank theme.
o Fixed a bug with variable typing causing an error on occasion.

I have started referring to the two tools as "SteamyDock" rather then just as enhancements to Rocketdock. The reason for this is that I want to make these two utilities part of Rocketdock's open source replacement and I've been searching for a suitable name. As I have bundled my steampunk icon sets within the tool, it only seems sensible to use the steampunk theme as part of their name. So, for the moment, SteamyDock is the name of the intended FOSS replacement for Rocketock.

I now also have an actual dock partially built, it operates and I am just seeing what I can do to make the code much more efficient than it is at the moment. I had a couple of pointers from Skunkie at Punklabs as to how they achieved the same in Rocketdock and I am following that lead. Thanks to Skunkie!

This is the actual dock functioning on my desktop, it is quite responsive but nowhere near as good currently as Rocketdock which it aims to emulate. It is based on GDI+ technology and that takes some getting used to.


If you compare it to the image at the top of this page which is the real Rocketdock you will see my new version just above is starting to really shape up.

Recent work to the new Rocketdock replacement, SteamyDock, include:

o The dock now initiates the same commands as does good old Rocketdock - it actually operates as a real dock!
o I have added a right click menu to the dock, just as Rocketdock had, currently non-operational.
o The dock now normalises the icons you supply to an icon cache at two sizes, the dock size and the 'blown up' 128 pixels.
o The dock reads from Rocketdock's registry entries and from the optional settings.ini file.
o The right click menu "screen position" is now configurable from the dock and it writes the settings as it ought, moving the dock as required but at the moment you have to restart to see this options change.
o The right click menu "autohide" option is now configurable from the dock and ditto.
o The right click menu "lock icons" option is now configurable from the dock and disables the delete option too -  and ditto.
o The right click menu "icon settings" option calls my enhanced icon settings tool.
o The right click menu "dock settings" option calls my alternative dock settings tool.
o The right click menu "Quit", quits.
o Now adding theme-ing so that the utility looks how it should on later versions of Windows - I hate Win10 with a vengeance.



o I have spent three days attempting to fix a bug that I had inadvertently introduced that prevented me from using images stored in memory. All now fixed.
o I have been tweaking the various timers that perform the animations and analyse the mouse movements, as a result the dock is now blisteringly fast.
o When an icon is clicked upon it now does a little bounce just like Rocketdock used to do by default.
o The icon descriptive text is now displayed when the dock is at the bottom and the top, now getting it to work when the dock is placed left/right.
o The descriptive text now responds to being enabled or disabled by the configuration utility.
o The descriptive text now displays just above the selected icon rather than in the centre of the screen as before.
o There is no longer any click-through on transparent icons.
o The distance from the edge placement is now functioning as per Rocketdock.
o A bug fixed where the incorrect tool could be initiated if the user moved the mouse during animation.
o The dock now resizes itself when the icons are being expanded  so it does not go off screen
o A hard-to-find bug fixed where the dock would propel itself off-screen exponentially, that was fun.
o The dock settings screen now checks for the existence of both docks, both SteamyDock and RocketDock.
o The dock settings screen now restarts SteamyDock if it is the default tool.
o The dock settings screen changes its title according to which dock it is configuring.
o The options that SteamyDock does not currently handle are greyed out in the dock settings screen.
o The dock now auto-hides as configured to do so.
o Added right click menus as per all my other applications.
o Added an "about" screen and the licence page.
o Created the full help for the dock.
o The dock now responds to configuration changes dynamically rather than needing to be restarted.
o The dock has been tested successfully with icons up to 256 x 256 bytes in size.
o The three tools have been combined to form one product with three separate components, for testing.
o Added a pause after applying dock configuration changes as the new SteamyDock starts so quickly that sometimes it does not receive the changes.
o Added the code to allow icons to be added straight from the dock by a right click - add icon option.
o Added the code to allow determination as to whether the program is already running so an indicator can be added to the icon.
o Added a white cog to each icon that has a running program associated with it. It looks better than the black triangle of Rocketdock and old versions of the OS/X dock.
o Added the code to select a folder without using a MS supplied VB6 ocx.
o Added the code to select a file without using a MS supplied VB6 ocx.
o Drag and drop has been implemented, Steamydock will recognise all the common Windows audio, video and executable types and give you and icon for each.
o Working now on the solution to reading the larger embedded icons icon within from a dropped binary.
o Created thirty or so new document icons for different file types.
o Fixed a bug correcting a stray icon being pushed incorrectly around the desktop.
o Created a question mark icon to replace Rocketdock's own default missing icon symbol.
o Created a rocket and globe icon to replace a similar Rocketdock icon.

SteamyDock actually works and I am now using it all the time instead of Rocketdock. This is quite a momentous time for me as it is the first time for more than 10 years I have not used RocketDock as the main dock on one of my computers. I'm finding the bugs in SteamyDock and fixing them as I go. SteamyDock already has several advantages over Rocketdock, firstly and most importantly, it is open source. Secondly, it runs using far less CPU resources than the original and it is fully supported on Windows 10 (as I am supporting it). In addition, it operates independently of its two settings utilities meaning that if either the dock or the config. tools are running slowly for some reason, each will not adversely affect the other.

I've currently restricted operation to either the top or bottom of the screen, imagining that no-one would use a dock on the left or right hand side of the screen. What do you think of this major departure from Rocketdock's functionality? Would you want to use a dock on the right or left hand side of the screen?

Lots of changes have occurred since my last post here and forgive me for not posting sooner. I have largely left DA well alone these days and I'm only rarely here to update a few sources of information.

So, what's changed?

o The original Rocketdock use two obsolete locations to store the icon and dock data. The default is the registry and the second is the settings.ini file in Rocketdock's own program folder. Both of these are standard locations back when RD was being designed but things have moved on and both these locations are thoroughly discouraged. Increased Windows ecurity means that accessing a file in the program folder location is a no-no and you may need admin rights for that and recent increases to security mean that accessing the registry entries for another process is also subject to security checks, requiring more admin rights... To avoid all this I have implemented a third configuration settings option that stores the data in the user's own appdata-roaming location, a preferred location for Windows and hopefully one that won't go obsolete.



o The dock is much smoother now as I have improved the bubble type animation as the icons pop-up, making the dock feel much more usable and more like Rocketdock.



o Identification of running applications are now catered for with a custom slider that reduces cpu usage through a timer.



o A significant memory leak has been plugged meaning that SteamyDock no longer consumes a lot more memory each time an icon is added.

o When the icon setting utility is opened from the dock it opens the specific icon that currently has focus allowing you to edit it immediately.

o I have added three new steampunk icon sets to the catalogue.



Earlier I stated that SteamyDock was nowhere near as good as Rocketdock - well, that is changing. The recent changes have made the dock much, much more usable. It is now slick to operate and run on a daily basis and it acts just like Rocketdock in most respects. I am cutting my teeth on GDI+ animation and it is not as easy to accomplish as you might expect. It is full screen animation and not object-orientated in any way. Not quite bare metal programming but in some way, closer to it. I have great respect for the Rocketdock devs when I look at the slick animation they accomplished.

I am using SteamyDock all the time now on all my machines, that is how much it has matured.

Latest news: Plenty of progress with the new dock. I've fixed bugs left, right and centre, including some long-standing difficult to find issues, attempting to make it more usable for testing. I have completed the tool's ability to write to the 3rd configuration file as described above. The testing begins. It isn't quite Beta quality yet but it is alpha-stable, some functionality not yet delivered but what there is, works well. It is tested on Windows 10, 7 and XP. No point in testing it on Vista nor Windows 8, nobody runs those...do they?

o Added the ability to read and write to different locations allowing easy transfer of a whole dock from Rocketdock.
o Bugs with the conversion of true /false text values to booleans turned out to be a VB6/Windows 10 bug with the CBool function.
o Truncation of long filenames bug found and fixed.
o More memory leaks plugged.

I've added a few new icons for fonts and a dinky little rocket has been adopted from Kludgets and adapted to suit my needs. I need a favicon and this little rocket will do nicely.



It has a new fin, a rocket exhaust, a new door and the porthole has been improved. I've also done some shading. More improvements on this small icon to make it fully my own expected shortly. I'm thinking of creating another set based on the these lines.

Progress is slow as I am a bit over-docked... but I have made some progress.

Rocketdock allows the display of a background theme that underlies your icons, I generally choose to run without such a theme as I feel it blurs the desktop/dock experience. However, some do find it useful so I have implemented the barebones of some similar functionality. The dock now reads the theme data, validates the values and I have added pseudo code to read the images into memory and display the result. However, the way that Rocketdock displays the image is rather strange, stretching the centre of the image whilst retaining the left/right portions. I don't know how to do that yet.

I have created twenty-eight themes based upon the originals provided by Rocketdock, they are similar though distinctly different enough to be called my own. Once again, I don't want to use Rocketdock native resources so I do have to create my own. I'm steadily working my way through the list.



This is the crystalXP theme replacement displayed using Rocketdock.

It turns out that replicating Rocketdock's themeing is more difficult than expected. You'd expect that Rocketdock would use three images for the background, one for the left hand end, one for the right hand and of course, the middle. It turns out that Rocketdock's background themeing is a lot more complicated than that. Rocketdock has just one image that incorporates all three images in one 118x118 pixel PNG. Rocketdock has to read the image into a bitmap, create a new cropped image that only contains a portion of the original image and then place it on the screen resized, and in the case of the middle image, stretched across the whole dock. It also does some strange additional cloning, cropping and stretching to create some of the effects of the non-square backgrounds. I tried to replicate this in code but realised part way through that it was a lot of work for little result as every time I tried, another glitch showed its head. So, I decided to break compatibility with Rocketdock and instead create a method that shows simple rectangular backgrounds using the three images I spoke about earlier. The skins still have the same names as Rocketdock's more familiar themes but they are achieved a little more easily and without the more elaborate shapes that Rocketdock has by default. Compatibility with Rocketdock themes can be done by someone else later. The code is FOSS after all. I spent a few days on this and came to a realisation that some of the things Rocketdock does are a little over-complicated. Someone at Punklabs was a graphical perfectionist that liked doing strange things in code. Some good came of it though, I've learnt a lot about how complex and annoying using Win32 GDI+ APIs can be in order to achieve anything at all.



The new 'ZakToon' skin on Steamydock.

Running Apps - The dock now retains a list of dock-initiated processes so that it can check programs in that list regularly to see if any recently-triggered processes are still running. If the user has killed the task then it removes the 'running' cog indicator from above the icon. Searching for just a few known tasks uses much less cpu than scanning all processes on the system. There is another such task still operating but I have reduced its frequency to once per minute so that the dock's resource usage is minimised. The idea is to make SteamyDock as streamlined as possible.



This is Steamydock displaying the running process 'cog' that shows the process associated with the icon is running now.

When using the right click menu I have also added the capability to kill a currently running app or run a new instance of it, both options are only apparent on icons with the running app indicator present. This actually makes the dock a lot more useful as you can both initiate, locate and kill apps from the same dock.



Rocketdock had a configuration option to open running instances of a program instead of a brand new one. Steamydock can now do the same. This code was far more tricky than I expected. It involved scanning all running processes, extracting the PID for the target process, enumerating all open, top-level windows, finding all threads associated with the PID and narrowing down the matching threads to extract the window handle. Then a simple task of using that handle to bring any minimised to the front. It works 99% of the time, I now need to refine it so that it works on tricky processes such as Firefox.


One of the things that Rocketdock can do is to place the dock on a second monitor, that's a rather nice feature during development as it means I can place Steamydock on the primary monitor and Rocketdock on the other, comparing the two. Having two very similar docks running side by side on adjacent screens is useful, fun and good for comparison. I now need to be able to duplicate the second monitor functionality with Steamydock. This is fairly tricky with Windows, VB6 and GDI+. I need to be able to sift through each attached monitor and obtain a device handle from each that allows me to perform the GDI+ operations on the chosen monitor. I have code to 'enumerate' each monitor using a callback function. So far my code works but nothing changes, it still paints to the first primary monitor, so some digging to do here before this function is achieved.



I have finished the new themes, twenty four of them and they all seem to display quite well. Rocketdock had a group of themes whose name preceded was with "astro". These had a rather strange set of spiky 'ends' and I was never really fond of them. I have retained the names but altered the images a little including appropriate planetary pictures to replace those ends with the addition of a few little sparkling stars.



I am tackling something I have never really need confident with, animation. So far we have the main dock animation that works quite well but do I need to improve it considerably as it sometimes becomes choppy on the intersection between two icons. Rocketdock had a few types of hover effect animation but I do not believe the different types were really ever used by many. Rocketdock emulated the OsX bounce animation and that is the main type I will replicate before I add more animation types of my own.

This is a work in progress but of course time is short and progress is slow. I have, however managed to add some animation options to the auto-hide action. There are now three types of auto-hide, a fade, a slide or an instant fade transform. The fade works very well, fading in and out as required. The slide option slides the dock out through the bottom of the screen but it does not yet slide back in but it will when I've finished. The instant fade works how it always did, instantly. Not easy stuff this but I am getting through it. Remember VB6 has no opacity functionality so that all the work has to be done in GDI+

I also have some new bounce code that I am toying with, we'll see how that goes.



This is a screenshot of the app thus far complete with astroOrange background theme. It is making good steady progress. Oh yes, and some new icons...



Life has been hectic during the Covid-19 lockdown, I am looking after my family of 10 of us all within the local vicinity. Due to this my time is now rather limited. Despite this, I have solutions for the multi monitor support problem, I am also re-writing the main animation to remove the 'bumpiness' when the cursor is placed on an area that the program thinks is mathematically 'between' the icons. I am creating new icon types and fixing and tidying in general.

I am also going through a nighttime conversion course on BASIC to C++ trying to get my mind onto the vagaries of C++ programming as that is a skill I currently do not have. My aim is to eventually contribute to the ReactOS o/s project is some way and C++ is a required skill there.

In addition to the above, I am keeping an eye on new technologies that might assist VB6 programming. One is a new tool from a duo of developers called TwinBasic. This is a VB6 dialect-compatible product that uses VSCode as its primary editor and produces code that can be used by the LLVM toolchain to produce native 64 bit binaries. At the moment it appears to be a tool for producing solely non-GUI BASIC programs such as OCX and DLLs. As such it is no good for the type of RAD design that was VB6's main strength but that functionality is promised in the future.

RADBasic is the second new technology coming in 2021. It aims to be 100% compatible with VB6 and will be RAD right from the start retaining VB6's ability to create and design forms but with the additional capability to create 64bit C++ binaries and handle 32bit OCXs within the 64bit process space. Both are interesting developments. The former seems to have some impetus and a valid approach but the latter seems to have the methodology that best suits my interests.

Covid-19 took my father at Christmas and it has left me caring for my poor dear mum. As such there is not a lot of time left to me to make new code but I am, somehow, finding the time. I have been working on the dock fade-out and fade-in animations, adding a new timer and slider whilst shifting the code into separate subroutines to make it easier to maintain and easier to work on in general. The fade out animation is a little smoother now too. The splash screen has also had a little animation applied and I'm testing steamydock on a test machine that has never, ever had Rocketdock installed. This is to allow me to make the changes to Steamydock to make it a product in its own right rather than just a tool that works with Rocketdock.



I have implemented a few minor changes to make the whole dock more usable on a modern desktop. When you are running an app in full screen mode you would often prefer that the dock has no presence on screen giving you the full space for your application. Rocketdock had that functionality allowing you to hide the dock with the default key sequence "ctrl+alt+R". I always found that to be a little cumbersome in operation and so it was seldom used. There was also no obvious method of reassigning this key sequence to something more useful like the F11 key.



To aid with this, I have added a new menu option to "Hide for the next N minutes" where the number of minutes is configurable in the settings. The dock will disappear immediately and re-appear after the assigned time is up. In addition, the option to make the dock go away immediately has been assigned to the key F11 or any other key the user chooses. One press to make the dock disappear, the second to make it return. The user can choose another function key if he requires.



I have fixed a few bugs with reading the bespoke themeing on one of the utilities and also a bug during the creation of a new steamydock process when saving and restarting. In addition there is a small improvement, I have added a new checkbox to determine if a post-initiation dialog should appear when clicking upon an icon. The reason this is present is that for some commands or utilities there is no visual feedback, for example I have an icon that is set to perform the following command:

C:\windows\system32\rundll32.exe advapi32.dll,ProcessIdleTasks

This is a method for freeing the cached memory pool run normally at the command prompt*.  This frees the memory but the problem is that the command itself does not provide any feedback that it has completed. The new checkbox option that I have added provides post-initiation feedback by simply opening up a dialog saying the specified command has been run.



(As an aside, nothing to do with the dock - *Windows 10 holds a lot of its structures in cache memory to speed up running processes and the o/s in general. If you are using Windows on an 8gb RAM system then you may experience occasional out-of-memory errors from Windows as it does not tend to release its own cached memory dynamically leading to memory shortages, even when you are not running that many processes. Running this command is a temporary fix. As the clear cache feature described above is quite useful, I have also added a new right-click menu option to allow the user to add a "clear cache" icon automatically - so you don't have to type all that command in by yourself).

I have been working on the code that enumerates windows, some code that used to work 99% of the time, I am improving it to resolve the final 1% of failed cases. When you click upon a minimised application it ought to maximise and this occasional failure is what I am attempting to repair.



The 1% of failed cases are programs that minimise to the Windows systray.  It turns out it is quite difficult to get the process information from the systray. The systray is just a standard toolbar and not really part of the o/s that can be queried as there are no Windows APIs to query the processes that reside there. However, I now have some donated code that can test for processes in the systray and I have shoe-horned that into my SteamyDock code. Steamydock can now maximise processes that have been minimised to the systray. Rocketdock couldn't do that!

Small change to the icon settings utility, when testing an icon, it now respects the dialog before/after check boxes when performing a test run. Dialog boxes should pop up just as they do in the dock itself.

I have tried to make two new commands operate correctly - "bring application to front" & "send application to back" are two new options on the right click menu for windows that are already open. The Windows o/s can set the z-order of applications to topmost, top or bottom but you cannot specify the actual order numerically and there is no bottommost. That is an absolute pain. My option to bring apps to the front works correctly but the option to set each to the bottom achieves an arbitrary result, sometimes it goes to the back and sometimes it does not. This seems to be down to the whim of the o/s.



I am creating a few new icons, just for the sake of it, replicating icons that are provided by Windows itself, rather than creating my own ideas from scratch. There are various shield icons used by the Defender application that are easily converted back to a more appropriate look and feel that suits Steamydock. I am creating these as PNG and .ICO files as well as bitmaps so they can be used by any utility and not just Steamydock.



The functionality to bring a specific Window to the front or send it to the back has been largely covered now. A few minor bugs were resolved by chatting to some clever C programmers over at the ReactOS group reactos.org/. They pointed me in the right direction with regard to selecting the correct APIs to use. In addition a few more icons have been created in the same vein as those above. I have been slowly replicating the icons that you will find in the Windows general icon library, some of them should already look familiar to you.



I just bought the domain that I will use to host and offer Steamydock to the unsuspecting masses, so I must be getting serious about the product!


Getting bored with your own project is something every developer needs to contend with. I deal with it by working on other things. It does mean that my projects tend to work better in some parts than others and I may become fixated on something only to drop it 90% complete.  Well, I am still doing that but I am also working on those 90% complete components too. Step by step, bit by bit. I bite off just what I can chew and no more.

I have overhauled the tool's documentation and help files. It now reflects the recent changes that have been made.

I have been working upon a dock auto-generation tool, one that looks at the user's system and comes up with a list of applications that are installed on the system. At the moment it looks into the uninstall part of the registry and the start menu folder location to determine what is installed on the system, there seems to be no other easy way of determining what a typical Windows system has installed... More research here to be done.



Regardless, I have a working tool that identifies installed windows apps and an interface that allows the user to select which he would like to be in the dock. It is a bulk add tool and so it currently has a day-to-day non-steampunk interface. A straightforward tool that is only used once or twice perhaps so is it worth the bother?


My current desktop showing SteamyDock in its current incarnation, still VB6, yes, still Windows 7.


And a few new icons...

Still working on the animations. My old method does not extend itself well to different styles of animations so I am starting on a new method that will allow for different animation types, this will require some investigation into using maths functions and a rework of existing code.

I am also overhauling the code for performance and maintainability, removing any unnecessary conversions from twips to pixels. What is a twip? Well, VB6 uses twips as its default measure of positioning anything, whereas GDI+ and all Windows APIs use pixels. Coming from a VB6 world, my program initially used VB6 methodology storing all object size and location information in twips and converting to pixels only when required to do so. The overhaul means that it now performs all calculations in pixels, resulting in the need for less conversion calculations, reduced CPU usage when animating and easier-to-understand code - as well as lending itself to easier conversion to .NET code later on, a language that uses pixels by default.



The above shows me trying to coax SteamyDock to use as much CPU as I can so that I can optimise the code prior to release. On my 10 year old laptop with a dual-core 3ghz core i7 (1st gen) the cpu usage is maxxed at 15-20% during cpu-bound animation. This seems a lot but the animation only takes place whilst the dock is being trawled. As soon as the application is fired up the cpu usage drops to zero. On my more powerful quad core 3.7ghz system, a similar vintage machine, the same animation uses only 4-5%. On a modern system I would imagine 1-2% usage at peak, on average less than 0.5%.

Something to note is that SteamyDock now runs perfectly well on a system that has never had Rocketdock installed upon it. The first two of my tools (icon and dock settings) worked with Rocketdock as that is how they were designed. The final component, the new dock itself means that Rocketdock as a component is no longer required. Therefore, the new dock has had to replicate all the structures that Rocketdock used and has to be able to run completely by itself. Lots of testing on several systems has proven that it does.

A few important improvements have taken place, the addition and deletion of icons is no longer a very slow operation as it was previously. It occurs in a matter of seconds.

Drag and drop has been implemented in all its different forms. Dragging a program or shortcut to to the dock had been added a while back but now a rotating hourglass timer is displayed during a drag and drop operation to the dock to show more precisely where the icon will be dropped. It is now possible to drag an icon away from the dock to delete it permanently, subsequently a pop up message box will ask you to confirm whether you really want to do this, the latter being something that Rocketdock lacked. Dragging from one part of the dock to move an icon to another location has also now been implemented, a smaller imageimage icon image is displayed during the drag and drop operation.

A rather important improvement is that one of the recent animation changes has come into effect, the dock icon bounce is now using an easeIN function to signify when an icon has been pressed. Nice to see a mathematically generated bounce!

Following on from the RocketDock Enhanced Settings Screen Pt 2 is our my new post - RocketDock Enhanced Settings Screen Pt 3! This will not be hosted on DeviantArt. The link to the new blog post will be presented here soon.
I