[VB6] Rocketdock Settings Enhancement

Excuse if this is in the wrong place, it has some graphics elements so it may fit here.

https://i.imgur.com/0UkRIKV.jpg

I use Rocketdock on all my Windows machines as I find the convenience of the MAC-style dock and the ability to customise is a real boon. Rocketdock was written by Punk Labs (skunkie et al) and was originally written for XP but was never overhauled for NT6 usage. It is no longer supported but it is still probably the best in its class. Rocketdock still functions as it should on Win7/10 but as time went on a few minor bugs crept in that decreased its usability. Nevertheless it is still an enhancement for Win 10 &c as that o/s has a fairly awful GUI and start menu IMHO.

One of the bugs is the time that RD takes to respond to an icon right click. It appears to have to trawl through each of the dock entries and parse the data before it can display the settings screen. I believe it is also reading the stored library of .ICO/PNG files so it can display a graphical selection of thumbnails for the user to choose. The bigger the icon folder the longer it takes.

As a result a right click can take 20-30 secs on a typical core2duo with an SSD and even on newer, faster systems there is a many-second delay. In addition, as each thumbnail is being read into memory (to speed up access?) there must be a significant memory overhead reading potentially hundreds of PNG images from the target folder.

So, I decided to write a VB6 replacement for this one bit of buggy functionality. Firstly, it is the only language where I stand a hope in hell's chance of doing it and secondly, because I am increasingly realising there is a mass of amazing code that can do anything using VB6.

This is the original settings screen:

https://i.imgur.com/KDvKdT1.png

This is my current replacement:
https://i.imgur.com/22EFCjl.png

It has been enhanced so that it loads the portable settings.ini file quickly, it also reads the registry if that is where the user has chosen to store the dock data.

It improves upon the original in certain areas: It indicates by number which Rocketdock item is currently selected; the user can delete unwanted icons directly from the file display; the ICO file previewed can be resized; you can flip to the next Rocketdock item without having to leave the settings screen; the start path is now selectable using a common dialog box; there are tooltips for all controls (before there were none), there is a help facility; the "get more" button takes you to a useful location where there are a lot more icons for the user to download; the whole thing runs faster. One final improvement is that the dock is only disabled when the native settings screen is used, that does not happen when using mine, ie. Rocketdock is still usable when my utility is running.

The only difference so far is that the file viewer top right, only displays the icon names and is not yet capable of displaying as thumbnails. I don't know how to do that yet, I am thinking of creating an array of objects that will use LaVolpe's graphical code to simulate a fileviewer in thumbnail mode. If you have any suggestions on how to achieve this I'd willingly take any suggestion.

I used LaVolpe's code for the previews as it was the easiest to integrate into my design. It can display all the icon types that Rocketdock might possibly encounter.

So far the new settings screen is very quick to open and do its stuff, certainly much faster than Rocketdock's settings screen.

I didn't intend to replace Rocketdock altogether, it just bothered me that I'd have to wait 30 seconds to change a simple icon. When I have this covered I'll think about the next thing I can improve.

I realise it might make no sense to recreate the whole of Rocketdock using VB6. Comments please!

Making good progress:

https://i.imgur.com/ef3LWYK.png

I've managed to simulate a thumbnail view of just 12 of the icons, each downward click on the vertical scrollbar loads another twelve images onto the picturebox array. The loading of just 12 images takes no time at all, much more efficient than loading the whole 836 icons as did the old Rockerdock screen (836 being just one library of steampunk icons from one source), there do exist steampunk libraries of over 3,000 icons.

I haven't yet figure out how to rescale PNGs loaded with lavolpe's loadpicture method but everything else seems to work. I haven't fully implemented the reading and writing of the registry locations yet but that is close to working. It does the job just as it should if a settings.ini is specified as the output.

PS. Those are all my very own steampunk icons.

Reading and writing the registry works fine now.

https://i.imgur.com/wZd3Fqt.jpg

Created a help screen called by button and right-click menu.

The main trouble with this new utility is that it cannot replace Rocketdock's own icon settings screen. It can't be integrated into Rocketdock as a replacement for the current right-click. It can however be called as one of the icons in the dock.

I also have an idea to add a mini version of the dock as a hideable element right in the middle of the tool. This would be a map of the dock and then I can emulate the functionality of Rocketdock and make selection and configuration of an icon much easier.

https://i.imgur.com/fDmk2XE.png
Just a mock-up.

The Rocketdock map has been completed, it works as intended and it scrolls left/right by simply sliding all the picture boxes right or left. The picture boxes are created dynamically according to the number of icons found in the Rocketdock settings.

There is a slider for the map, quite necessary when your dock has 70 or more items. The map is hideable so that you can restore the look and feel of the old Rocketdock settings screen.

I have added right click menus, 'about' and 'licence' screens.

I discovered that when I made changes to the settings.ini or the registry then Rocketdock overwrote those changes as soon as it exited. Instead, I have made all the icon changes to an intermediate settings file and only then used that to replace rocketdock's settings once I have killed the rocketdock process. It is then restarted automatically to show the resulting changes in the dock. There is a new save & restart button to implement this. Much more complicated than I expected.

https://i.imgur.com/QZiD85H.png
My first build of the Rocketdock map. The icon map is still having trouble resizing PNG images, I will fix that at the end. It works find for .ICOs.

I have implemented a backup system that allows the utility to take and store multiple settings files in the form of:

settings.ini;1
settings.ini;2
settings.ini;3

Each backup causes an increment of the version number (a la VMS) so you can go back to a previous backup of the dock any time you want by simply renaming one of the backup settings files to the current version. A backup occurs automatically each time the utility is operated and there is a new backup request button so that you can take a manual backup if you so wish.

The treeview now works as intended allowing you to select a sub-folder holding icon collections

The tool now also pops up the licence screen when it is run for the first time and it remembers any tool-specific settings.

I have now added the "add item" right click menu allowing the tool to add new icons to the map and thence to Rocketdock after a restart.

The delete item is next...

o Deletion of an icon from the map has now been implemented.
o The program can now extract icons embedded within a DLL or an executable.
o Added a "working" indicator on the initial creation of the map.
o Add the ability to save copies of the settings files used.
o Read the user-configured folder on startup and automatically set it in the treeview.
o Changed the underlying image display code to allow the utility to handle image sizes.

https://i.imgur.com/dR9FCoc.png
An image of the utility working on the desktop.

Still using Lavolpe's code but this time using the code from Lavolpe's prj32bppSuite. It is slightly more CPU-heavy than the earlier version but it works. It also has a problem with dealing with certain ICO types that cause it to display the ICO with lines in the mask leaving black striations. It only occurs with ICO files so some debugging to do.

It also crashes the IDE when the above bug occurs, causing the vertical scrollbar to freeze and then some short time after that the IDE will close unexpectedly.

https://i.imgur.com/Np7ysjN.gif
Here is an animated GIF of the utility in operation, forgive the low quality capture. It gives an idea of the way it operates.

I've been in contact with Skunkie from Punklabs, one of the original developers of Rocketdock who I've known through the internet for a few years now. I didn't want to show her anything until there was something that worked in general. She was pleased to see the development of the new utility and said she was pleasantly impressed. It is always good to get the blessing of the developer of the original tool even though I am writing it from scratch and the only similarity is the look and feel.

I've added the ability to move an icon in the Icon Map. A simple right click brings the option to 'move item to the left' or to the right. I have prepared some code to allow a specific icon on the map to be dragged left or right to a new location but the way that the cursor currently picks up the icon feels 'wrong' and imprecise so I will revisit that later.

https://i.imgur.com/Z4660NK.jpg

I've added another built-in icon folder to the treeview for the user to select if he or she so wishes and the delete folder button now removes a treeview parent node, another Rocketdock bug fixed, on the original RD settings tool it did nothing at all.

https://i.imgur.com/1ujTsER.jpg

o Added F5 keypress to the map and the thumbnail view allowing refresh via keyboard
o Fixed some bugs re: caption generation
o Added HOME and END on the rocketdock map
o Added custom folders containing icon sets
o Removed a lot of unnecessary code
o Tidied and commented the code somewhat to make it readable
o Added mousePointer busy cursor and various point to signify 'working'
o Testing various methods to extract the larger embedded icons from a DLL or EXE - taken me a while to no avail, so far...

No new imagery to display. Getting close to completion in many respects.

I do hope you don't mind me posting this work-in-progress. Personally I find the creation part of a project by far the most interesting. I wish more devs would show this part of a project's inception.

I've added an animated busy timer to the central part of my utility that gives a fairly prominent clue that something is going on.

https://i.imgur.com/yiTJyuu.gif

The slider bar now operates and scrolls the Rocket Dock map from left to right.

o in the folder treeview renamed the custom folder to "custom" and my own icon collection to "my collection"

o added a "Generate Dock" that is intended to make a list of software installed on the system and then auto-generate a complete new Rocketdock using known icons that match. Incomplete.

In addition to the icon settings utility I have created a VB6 version of the dock settings utility that comes with Rocketdock.

https://i.imgur.com/b29sY9m.gif

At the moment it is just a mock-up that does nothing but allow selection of the different panels with the icons on the left. I have to extract the code from the icon settings utility to allow it to read and write from the registry and settings files but that's about it. It should be relatively straight-forward.

When this utlity is done it will complete the tools that come with Rocketdock allowing it to be fully configured.

The only real life advantage of using this utility rather than the original is that the dock is still functional while this tool is operating. The other advantage is that the new version will be FOSS and could form a basis for a new and FOSS version of Rocketdock later. I doubt that it will be done using VB6 but that's another story.

-oOo-

On the Rocketdock Enhanced Settings utility I have fixed the bugs surrounding the Rocketdock Map and its slider and it now operates as you would expect.

https://i.imgur.com/JqG1boI.gif

To complete, all I need to do is document and tidy the code, fix a few very minor bugs and then test on other versions of Windows (XP and win10)

I have one serious code change to implement to allow it to extract larger sizes of embedded icons from within EXEs and DLLs but that will be my final fix before I release version 0.9.

-oOo-

Updated the help screen, polished a few of the graphics, working on the code to read the larger icons, just need to get it to work!

On another note, how annoying is it to create something only to find later that a control exists to do exactly that sort of functionality already? I didn't realise that there was an extant imagelist control and I created something just like it by hand... oh well, you live and learn.

Also added the ability to change the font for all labels and visible text boxes, I do like to have the facility to customise a tool and think it should be present in all Windows programs across the board. Too many programs have a font hard-coded in.

https://i.imgur.com/jgJlH2p.png
An image of the utility sporting the Centurion Light font:

I've managed to extract larger icons than 16x16 or 32x32bpp from being embedded within DLLs and EXEs. The World of Tanks Icon in the image below is an example, it is 256bpp.

https://i.imgur.com/wxQfEod.jpg

Removed documentation for PrivateExtractIcons to another thread here:
http://www.vbforums.com/showthread.p...m-a-DLL-or-EXE

Probably my final animated GIF - shows the utility using the Mostra one font, It all works, at least everything I originally had planned for it.

https://i.imgur.com/d6eYZgi.gif

I now need to package it up so the binary, the settings.ini and the .OCX files are all bundled in a single SETUP.exe. I have not yet found a packager that does what I need, my old packager setup2go does not place the ocx files in the correct location nor does it check the versions to avoid DLL hell. I had expected that on a mature location such as this that a suitable tool would have been created long ago but I seem to be unexpectedly disappointed.

If anyone knows of a good packager then I'd be pleased to take your recommendation.

Well, bar one bug I have finished the tool and it works in all respects just as I planned it. I am rather pleased. I encountered a rather unexpected and for me a large stumbling block with regard to the packaging of the utility as described above.

As we all know VB6 projects often utilise objects called OCXs. For those that don't know these are packaged libraries of functionality that provide additional functions to your program such as common dialog boxes (file open/save) or treeviews to your GUI or similar. These OCXs are bound to your program and are required to be present and 'registered' on the target system. This wasn't a problem when VB6 was young as I believe all or the majority of windows machines had these OCXs available and present - but as time has gone on, the later versions of Windows may not have them, might have a different version but they certainly won't be registered.

So there is the problem. How to bundle the OCXs with my binary and have them automatically placed - correctly into C:\windows\system32 for 64bit systems or C:\windows\sysWOW64 for 32bit systems - and then registered using administrator rights. I have looked for packagers that understand VB6's specific requirements (with no luck or they cost good money), I have tried creating SxS or side by side manifests (another bad solution provided by MS) that always seems to fail due to one thing or another. I've spent spent hours on this and all I want to do is to package my binary...

In the end I gave up on all that, brought out an old tool I have in my arsenal - setup2go, a fully-functional free packager with a decent GUI that does all that I want.

https://i.imgur.com/TlkHk4n.jpg

In addition I wrote my own VB6 tool for dealing with OCX distribution and registration. That is what I am testing now. A little more testing and I'll have it finished soon and my VB6 project will be complete and available for download. I expect that as many as four to five people will download it per week... :( if I'm lucky.

https://i.imgur.com/I8iqICQ.jpg

My OCX registration tool - first cut - no nonsense.

I'll have to find some good places to distribute it. In truth, the number of users does not really matter. For me it was a technical challenge to free up the brain cells, to learn new techniques and see how well an old technology is suited to resolving current day problems. In one sense I also created it purely for myself to keep Rocketdock usable under Windows 7/10 today and in the future.

https://i.imgur.com/MbZhd6k.jpg

The splash screen shown during installation.

The next step is to migrate the exact same design to VB.NET and to learn the perils and pitfalls of that process, going from a cosy place to an unknown one. When I was a Project Manager I managed people to do this sort of thing for me but without ever really going through it on a technical basis myself. Now I am doing the technical role, I can appreciate how complex design and coding really was.

-oOo-

https://i.imgur.com/8j4c0jY.jpg

I've added some right-click menu options to the icon map allowing you to assign various functions to pre-selected icon images. I am also adding the same selection options to the icon target selection button.

In addition, if the user closes the utility with the Rocketdock map showing, the map state is remembered when the tool is re-opened. Just a few minor improvements but these little changes make all the difference.

-oOo-

I've removed the need for one of the additional OCX files, the one that provides the rich-text control used for the licence display and auto-generated software list. Instead of rich-text boxes I now use a simple listbox which is part of core VB6 and thus does not require this additional functionality. It means that one of the external dependencies has been removed. I aim to remove the remainder of the required OCXs but that will be more difficult than you might expect and might take a while.

I am working on the thumbnail display (top right) to make it act more like its Explorer counterpart with regard to keyboard presses.

beautiful

Quote:

---

Originally Posted by xxdoc123

beautiful

---

Very kind. Your positivity appreciated.

My creations tend to be more focussed on the look-and-feel of the app. Secondly, the functionality and I suppose any expression of programming ability probably comes last of all. I just code and do what comes into my head rather than planning and documenting. When I eventually release the program source code I expect some criticism of my terrible (though improved) programming methodology. I'll have to develop a thick skin.

Thanks again.

I have added a debug mode:

http://www.vbforums.com/images/ieimages/2019/08/1.jpg

This will help users to report bugs if there are any. When you are debugging a program it is relatively easy to carry out using VB6's built-in IDE whilst the code is being interpreted. However, runtime bugs that are generated after compilation are more difficult to find. This utility was written by a VBforum contributor by the name of Elroy. It makes it much easier to see which function ran last prior to a bug being generated.

-oOo-

https://i.imgur.com/tlsZYwi.jpg

I have managed to remove another of the external dependencies, namely the common dialog box. I am using direct calls to system APIs to open dialog boxes for font, folder and file selection. This removes one more OCX that was previously required to be bundled with my compiled exe, comdlg32.ocx.

https://i.imgur.com/bPVv4R0.jpg

Just one more OCX to go, that being comclt32.ocx which provides a slider and treeview functionality, I can re-code the slider myself but the treeview will be a bit more tricky. I have a version that is working, I just need to perfect it.

http://www.vbforums.com/images/ieimages/2019/09/1.jpg

Top left is the new treeview created using a win32 API that I implemented but abandoned as it was simply too much work and I want to finish my tool. It operated largely as the previous version except for a current lack of tooltips and I haven't yet figured out how to select a particular node in the tree as the default folder. A window created by a Win32 API appears to lack some context with regard to the VB6 form on which it sits. I've had to move any underlying controls such as frames as they were intercepting click events and preventing the API generated treeview from operating as it should. These API generated controls are hard to interact with.

I realised that to do anything using APIS seems to require reams of constant declarations and code to pull handles from everything. Nothing is easy and it all takes forever to investigate code and debug. Especially when you are starting at the point where I am, from a position of no knowledge and little understanding.

The functionality I am missing now:

1. Automatically selecting a specific named item in the treeview
2. Deleting a specific item in the treeview
3. Regenerating the treeview
4. Generating tooltips for each treeview item

It seems that it isn't possible to select a specific named item in a treeview, instead you have to loop through each item in the list and then compare the value of each item to the value you have stored. Clearing and regenerating the treeview causes the node highlighting on the treeview to disappear.

The level of complexity and the vagueness of debugging results has made me question my use of APIs to do this. I may put this attempt to replace the OCX treeview on the back burner until I feel more confident. So, at this point in the development I abandoned rolling my own treeview and I am now currently back on my older code that includes the OCX treeview in mscomctl. I am also experimenting with Krool's replacement controls for the treeview and slider.

This means I can complete the utility now and add extra functionality later. Everything will still work as expected, I'll just have an extra something to bundle into the installation.

https://i.imgur.com/ZD4W94R.jpg

In addition to my Rocketdock settings utility, I have found an open source dock on planetsource that suits my utils perfectly, the above is an image of it on my desktop. It looks very similar to my standard Rocketdock. It is written in VB6 and uses GDI to do the graphics work. It was written by a chap who goes by the pseudonym of Peacemaker2000. He has written a couple of versions of this program, one using DirectX8 and the latest and much quicker version using Win GDI (graphics device interface). It runs fairly well on my old 2.5ghz core2duo but it is nowhere near as efficient in handling graphics as Rocketdock - but it works! OK, it is VB6 and I wouldn't expect it to run as fast as C++ but there is still room for improvement, no doubt.

You can find that GDI VB6 dock here.
http://www.planetsourcecode.com/vb/s...gADt89kshwIFSM

I intend to modify my two utilities (settings & config) so that they work with this new desktop dock as well as old Rocketdock. It will mean some changes internally to identify which dock they are currently handling and some additional changes to the new dock's code to enable it to write its configuration and settings to both a settings.ini and the registry in the same way that Rocketdock does it. The good thing about this new dock is that it is open source so anyone can make a change and it is relatively new. I wish I'd known about it earlier.

-oOo-

Back onto my Enhanced Settings Utility - I have added the capability to add Rocketdock docklets, fixed a few minor bugs with the thumbnail folder view. I'm doing lots of testing on different machines displaying other visual themes to see how an old VB6 program operates with those themes in action. One small improvement in functionality - I've added the capability to test run any icon in the dock.

I have largely finished the tool and I just need to test the installation on a few machines here and there - so I am looking for some help and assistance. If anyone, a current Rocketdock user or a potential Rocketdock user would like to test my tool then I'd appreciate the help. You'll need to install Rocketdock and my tool separately and see how it works, what the problems are. We must expect it to cause a bug or two as it is still Alpha grade software.
PM me please if you are willing to test for me.

-oOo-

A few bugs fixed regarding adding the Rocketdock docklets. Deletion of an icon in Rocketdock's dock now generates a message asking if you really want to do this. Themeing bugs have been fixed.

I've updated the full help image for it and I'm thinking about writing a proper text help file in full - more work but it might be necessary.

https://i.imgur.com/AfOgpTL.jpg

o The full text help file has been written and packaged in PDF format and is now accessible from the main right-click menu.
o I have added the capability to restore a backup file at will, there is now an interface that allows you to select a backup file and have the settings it contains incorporated into Rocketdock by a simple button click.
o The file title and dock entry target fields are now filled in automatically if they are blank.

Testing on Windows 10 proves that it works on my Windows 10 Home laptop and on another user's Win 10 system.

I have a couple of changes to perform:

o writing the local settings.ini file to the application data folder rather than a settings.ini in the app's program files folder.

o It currently runs from a "programs" folder rather than the "program files (x86) folder. The reason for this is that it bypasses some of Windows' security settings. I need to run it in the correct folder for long term usage and in order to release it to the world (!).

Simultaneously, I have migrated the whole application to VB.NET (2005). The migration tool is present in all of the early versions of Visual studio and despite my misgivings of its effectiveness, it has done quite a thorough job of conversion. It found quite a few elements that it could not convert but a lot of that was in code that I would not need in any case. All the image handling code that allowed transparencies and image support for TIFFs, PNGs and other non-native formats was deleted as VB.NET does that image handling natively without need for extra code. File, font and folder dialogs don't need external OCXs to operate so there are no external dependencies.

I am making any changes from this point within both environments, easy to do as the VB syntax is very much the same. The program does not yet run as there are a number of runtime bugs and problems to resolve but there are no longer any major errors preventing a build. Good progress for just a few hours work. I have great faith that this migration will succeed and the resulting program will be easier to maintain. The VB.NET IDE (2005) is similar enough to the old VB6 IDE to be usable, it is a little slower and a little less fluid but it is usable.

I will soon have taught myself how to design, build, run and package a VB6 program and how to migrate it to VB.NET. This what I set out to do and I have something that works to boot!

https://i.imgur.com/TwbZtB8.jpg

I have struggled with the VB2005 Express IDE and have fought a battle to get it working. It is an old product and limited in some key respects, however, it did the job and managed to migrate the old VB6 code into something resembling a .NET compatible version. The 2005 and 2008 versions both include a VB6 migration tool unlike the later versions (2010+) and unlike others, I was rather impressed by the results. The trouble is the conversion still requires a lot of human legwork. it does the basics but I still had to convert a lot of the code myself. The final battle with the debugger almost made me despair and give up as it would just not do what it was meant to do getting its compiled binary and source code continuously out of synch. (getting its knickers in a twist). Rather than give up I downloaded a copy of the VB Express 2010 ISO from the Wayback machine's version of Microsoft's site and installed that. It worked first time. My original installation of VB 2005 was 'borked' as they say or it could not handle the results of its own migration. Anyhow, in 2010, the code builds and debugs as it should.

With this in place and working, I have removed all the reams of VB6 code that were related to reading TIFF, PNG, JPG, BMP, ICO and GIF images and replaced all of that with just three lines of code. The VB6 lack of native image handling for those types was severely limiting but VB.NET has that properly covered.

https://i.imgur.com/trCrzaq.jpg
It is starting to really look like the VB6 version.

The above image shows icons being read and understood and correctly placed (except for the preview). One small improvement over the VB6 version is that the .NET code can easily extract the image sizes (width, height) and display those for each previewed image. It is possible to extract that same information for some image types in VB6 but you have to be creative to cater for all types. I have been creative and added that functionality to both versions.

I'm keeping the two programs in synchronisation so that the code for one matches the code for the other where it is practical to do so.

Initially I noted that the natively resized images shown in the .NET version have lost some of their detail resulting in a lower quality image displayed when compared to the VB6 versions. The difference isn't marked and is not present in the full size version but I didn't want any reduction in quality in the final product when simply upgrading the tool used to build the program. With that in mind I rejigged the code to use a graphics routine to retain more of the detail and I've also added a switch to allow the icons to be shown in low quality (fast) or high quality (slower).

What's to do in order to complete? Well, keypress and focus events are still not working after the migration and the selection of icon types does not select an icon type, for some currently unknown reason. I have to look at the simulation that the migration tool has performed on the few control arrays I have used. I may need to re-code these. I also need to remove any old VB6 methods of doing things, (twips &c).

https://i.imgur.com/vhLsrXY.jpg

Right! The migration is complete. I now have a working version of my utility in VB.NET form. This was a much harder task than I was expecting it to be. However, it looks, runs and operates exactly as the original VB6 version which was the whole point of the exercise, to teach me how to program using VB.NET and to result in a more future-proof version of the program.

The amount of work to migrate a program from VB6 to VB.NET is anything but trivial. Almost every command, function, method, property has changed in either a very subtle or major manner, each resulting in a major difference causing syntactic or logic issues. Each change requiring time to uncover, investigate, test, re-implement, comparison and more often than not, a fundamental re-code. A VB.NET migration feels as if your program has suddenly decided to grow lots and lots of bugs.

When I created the VB6 version of the program I realised that VB6 is capable of doing anything, 95% of what you create is easy, yet that last 5% of difficult use-cases is really tough going. Regardless, VB6 CAN do it but only with a lot of effort. The amazing thing about VB.NET is that it makes that last 5% really easy to do, bringing system level and advanced functionality into the framework and making it easy to access. However, VB.NET makes the rest, the easy portion, the other 95% - much more difficult to achieve. Nothing is straightforward and nothing is how you expect it. Setting a background colour?

lblThumbName.BackColor = System.Drawing.ColorTranslator.FromOle(&HFFFFFF)

in VB6 it used to be:
lblThumbName.BackColor = &HFFFFFF

So much has changed in VB6 - VB.NET that the two languages are really largely incompatible. Despite the syntax and the logic being the same, the methodology and implementation can be so different that any migration is stymied at almost every step. VB.NET has much greater flexibility and offers so much more but is also so much more complicated, often needlessly so as the above demonstrates, whereas my gut feel is that something is fundamentally not right with VB.NET - ie. BASIC should be basic!

VB6 has a place in the world. It is closer to its BASIC roots and therefore more suitable for beginners and hobbyists, yet it has capabilities far greater than that. For a VB6-er, working in VB.NET is akin to talking to someone who learned English in another country by listening to pop songs on the radio. It sounds familiar in some ways but is garbled and so annoyingly different from the language you know and understand that it prevents expression and exchange of information. Despite being so much more technically, VB.NET feels crippled in the way it literally prevents you from bashing out code by arcane syntax and unnecessary complexity. RAD it certainly isn't, the successor to VB6 it definitely isn't, it feels like another tool that someone gave the visualbasic moniker to by mistake.

My feeling is much the same as the first VB6ers who encountered VB.NET all that time ago. I am impressed by the scale of VB.NET and see the power of it and how it could future-proof my applications. However, I can tell that the team that designed VB.NET failed in their vision of creating a replacement for VB6 and ultimately failed in their task. They failed to understand the strengths of VB6 and the crowd of would-be developers that it suited perfectly. Someone senior at Microsoft had a disdain for BASIC that coloured their judgement and caused them to try to force an unnatural combination of the .NET framework onto VB6 to create the monster that is VB.NET. Perhaps it was design by committee but the end result was something that largely killed off VB programming on Windows. Many would argue with this but once upon a time everyone, every man and his dog was programming in VB6, anyone could as VB6 was so accessible. VB6 was the world's most popular programming language. Today, the situation is drastically different, the number of developers programming in VB is just a small proportion of those developing in .NET, possibly less than one fifth. Developers abandoned VB in droves once .NET got under their skin, those that liked what they saw in .NET realised that C# was the future and those that loved VB6 realised it was time to get out.

Fundamentally there is no reason for VB.NET to exist except as a stepping stone for would-be C# programmers attempting to learn the .NET framework.

It has taught me that I would not recommend VB.NET to any programming noob, no beginner should pick it up and start from there, is it NOT BASIC. It also taught me that it is also not the target platform for any VB6 migration as the workload is simply too much for any large existing project. My utility is probably 9-10,000 lines of code or so and at every step I was stymied by this or that and I can tell you it felt like a lot of hard and unnecessary work. I had a working program in VB6 so why should it be so hard to create a working one in VB.NET?

Well, I would now completely agree with all the devs that told me that a VB6 migration should not be attempted but that in fact it is better to re-design any new VB.NET program from scratch. I think this tells you why VB.NET has been unsuccessful.

What have I learned? Honestly? there IS room for a new VB7/VB6.N that builds on VB6's legacy. The same IDE, improved. The inclusion of system.IO APIs and the handling of newer transparent images. The creation of 64bit binaries and a future outside of the hands of Microsoft.

If that product existed I would use it and the future of thousands of VB6 projects would be assured. and it might bring would-be programmers back into Microsoft's ecosystem. However they can't do it, everything Microsoft does is "design by committee" and their strategy is not suited to serving chaps like you and me.

https://i.imgur.com/JqBjtt9.jpg

Those of you who don't want to hear my ramblings don't read on. This list of problems I encountered just shows the immensity of the issues you will encounter in a typical VB6 to VB.NET migration. Do understand these aren't all negative but they do all have to be taken into account.

I know this stuff is old hat to a lot of you but this migration is what I set out to do, to learn what the typical problems might be. It was new to me and I've learned a lot.

Issues caused by the migration itself
==========================

o The migration tool inserts onchanged rather than onclick events that causes multiple unwanted event to trigger at form initiation, they have to be changed back again to .click events or the event handled to tame it.

o The migration tool does some strange things, turning a scrollbar_change event to a procedure rather than converting it to a valuechanged event that would be more appropriate.

o When the migrator migrates the COM based slider it fails to translate it to a .NET trackbar

o When the migrator migrates the COM based treeview it fails to translate it to a .NET treeview

o string declarations now need assignment before usage or the migrator complains with a !
object declarations now need assignment before usage or it complains with a !

o Unlike other migrated events the migrator fails to replace the old events with the new MouseLeave or MouseEnter events leaving you to migrate the routines yourself.

o The migrator tells us that frame events FrameFolders.MouseDown were not upgraded. That is bollox. Frames are now groupBoxes and the mousedown is now a mouseclick. That should have been easy to handle.

Private Sub FrameFolders_MouseClick(ByVal sender As Object, ByVal e As MouseEventArgs) Handles FrameFolders.MouseClick

o VB6.FontChangeSize(
VB6.FontChangeName(

New Font(suppliedFont, suppliedSize)

Strange that the migration tool does not automatically change these but instead uses a compatibility for the two separate functions.

o The VB6 frame allows borderstyle to be set to 0
.NET has removed the .borderstyle property of the frame's replacement, the groupbox. The migrator actually converts frames to groupboxes introducing this problem meaning that you have to manually change the groupBoxes to panels yourself.

My first impression of the migration tool was a positive one but as I moved through the differences that it did not take into account then I realised what a useless tool it really is. Still, it is a starting point.

Quote:

---

Originally Posted by yereverluvinuncleber

... Setting a background colour?

lblThumbName.BackColor = System.Drawing.ColorTranslator.FromOle(&HFFFFFF)

in VB6 it used to be:
lblThumbName.BackColor = &HFFFFFF

...

---

I guess I usually set a color either using a standard color, or the FromArgb method.

Code:

---

    lblThumbName.BackColor = Color.White
    lblThumbName.BackColor = Color.FromArgb(&HFFFFFFFF)

---

Never heard of the ColorTranslator.FromOle method. Perhaps that was how the migration tool chose to convert from VB6 to .Net

Of course, with the FromArgb method, since you specify A the color can be translucent.
lblThumbName.BackColor = Color.FromArgb(&H80FFFFFF)

General differences encountered when migrating from VB6
=========================================

First of all, in VB.NET Events are not automatically tied to subroutines dependent upon their names. The events are triggered by this sort of a string - "handles TreeView.Click" and the event parameters are passed in this manner "(ByVal eventSender As System.Object, ByVal eventArgs As System.EventArgs)"

This means that ANY subroutine can be triggered by any control event by adding the "handles event.click" or similar to the end. This is the first major difference that will affect you when knocking out code. It is something a VB6 programmer must learn.

o Raising events on other objects seems to be needlessly complicated in .NET, why not simply just do a object.click()? Now the event and the sender also need to be passed to the called routine, I do get it but some of it could be optional. So much in .NET is over-designed and the result is over-complex. Thank goodness for javascript, my 'other' language.

o Sometimes the error messages are cryptic - leaving an extra bracket by mistake can generate an obtuse error rather than just highlighting the location of missing bracket. Failure to declare a variable can cause an "unable to determine the default property of an object" message.

Thankyou Passel, not all of this is going to be correct, just some of my observations from what I found, your corrections will be absorbed.

Serious structural differences between VB6 and VB.NET
======================================

o When you have a dynamically created control array the migration tool creates a dummy control to replace the required VB6 position 0 control, it is created with _underscores_ before and after the name and it somehow catches events for the dynamically created controls

Control arrays don't exist and are implemented only in VB6 compatibility mode. In .NET the array's index property is retained being exposed by the migration as a property for a master control. Control arrays still work in principle straight after the migration. However, this functionality needs to be removed as soon as possible for your program to be compatible with .NET methods of doing things. This VB6 compatibility mode is obsolete and will not be retained by Microsoft in the future.

o The correct method to implement an array of controls requires creation of a control collection as a class.

msdn.microsoft.com/en-us/ie/aa…

For each new collection a new class needs to be created, for each control type a new collection needs to be created.

In .NET it is much more difficult working in the IDE without the VB6 concept of a control array. With a dynamic control array, all the members of the collection are created at runtime and there is no control for you to double-click upon in the IDE that can take you directly to the code you require. Without that visible 'stub' control array member 0 showing in the IDE you have to remember the name of the control and then remember how you created it, finally finding the event associated with it. It is all very long-winded and cumbersome and a retrograde step away
from WYSIWYG.

I find it is often easier to work with the VB6 IDE, to identify the control in an array and the events associated with it. Then move over to Visual studio and find the code by name. VB6 wins in usability and in the power of control array to free the programmer from the drudgery of writing code to do the same.

Note that when a 'master' or zero control in a VB.NET migrated control array is deleted and manually re-added in 2010 the index property is subsequently not recreated unless a line is manually added to the designer.vb that causes it to be displayed in the properties window.

* Note to self: do not delete 'master' or zero controls in a VB NET pseudo control array when using the VB6 namespaces *

o Popupmenus are initially a pain under VB.NET. The interface is very different and the concepts seem a little over complicated at first but when you realise they are just menu objects with a new UI to create them, then it becomes acceptable. However, it has to be said VB6's menu creation tool was a bit useless.

Menus under VB.NET by default are vertically challenged. The vertical spacing is too great resulting in long and extended menus compared to VB6's more compact and tighter menus. Despite being objects, .NET menus do not have those attributes that allow them to be easily styled with regard to the height of the menu entries.

o VB net ToolStripMenuItem image margin removal

Some contextmenu properties are not inherited by their submenus, for example the contextmenustrip has a showimagemargin property that removes the menu image space. The submenus are implemented using ToolStripMenuItems and they do not inherit this property from the parent context menu. It HAS to be set in code and cannot be set at design time which is a bit rubbish. Also, none of your menus in the designer match how they will look in the running program. You and everyone else will waste lots of time looking for the property that allows this to be set in the designer... It does not exist.

o Tooltips in NET, in general are a pain, more complicated then they need to be. Rather than being properties of the object they are now objects in themselves and are assigned to objects.

In treeviews, they can also be properties of nodes in a treeview as well.
On a treeview when assigned at the treeview level they appear exactly at the mouse position which is sometimes a pain and need to be reallocated in position manually. In contrast with VB6 the position of the tooltip for the treeview is determined by the position where the tooltip first or last appeared. I prefer the latter as default behaviour but with .NET you have more control. There is a lot of tooltip flickering with .NET that has to be handled with code preventing a new tooltip being auto-generated when the old is already present. VB6 tooltips were simple and easier.

o The treeview selected node on a click event, .NET now selects the previous node and not the current one, you have to use the after event to select the currently clicked node. The migration tool does not tell you this!

The treeview lowest level is now 0 and not 1

selected node

TreeView.SelectedItem.Key
TreeView.SelectedNode.Name

o A MAJOR flaw is .imagefromfile compared to .LoadPictureFile in VB6. The .NET version locks the source until the application exits. This is a Microsoft 'intended' feature. The dispose command does release the file but in addition it removes the image control itself and makes the control unusable when it is part of an array and the whole image array has to be recreated. In VB6 you simply delete the file without all that hassle.

So, instead of imagefromfile, I have to read the file into a memory stream:

contentBytes = File.ReadAllBytes(file_name)
memoryStream = New MemoryStream(contentBytes)
image = image.FromStream(memoryStream)
picImage.Image = image

This does not lock the file and is not appreciably slower.

o The files list box control has not been replicated. You have to roll your own using a list box.
The trouble is that the vb6 control has three properties that the list box does not have that you will have to emulate yourself.

'.Path none - need to do a reload each time it changes
'.Pattern none - need to do a reload each time it changes
'.filename none - need to determine which is selected and do a reload each time it changes

I created a routine that would clear and repopulate according to a pattern match or a folder selection. The .filename was replaced by a .selecteditem. Not so difficult in the end but when the functionality is called in so many places throughout your code it leads to a lot of changes and a lot of testing. After a lot of searching I found no examples of a replacement control, no-one seems to have posted an open-source alternative that can easily plug straight in.

o The key handling is a pain! if you use the keydown event, so much has changed that all your code needs rejigging.

There is no key down event in .NET panel nor picturebox controls. This seems a strange oversight as you might need key events to register on these controls and a retrograde step as VB6 already has these events for groupboxes and pictureboxes. All key capture events need to be captured on the main form and not in the various controls as several of the controls don't have gotFocus or keydown events.

The cursor keys are NOT captured by at all by a form1_keydown and so you need to add some form override functions to capture all key events. You have to remember to turn KeyPreview to True for the form otherwise key events won't register regardless of what you do and by default it is OFF.

You have to resort to the primitive handling of all key events at the form level and then add your own gotFocus global variables be set during a .mouseDown event for all the controls that you want to register a keydown. When the keydown is captured on the base form you have to use these variables to determine which panel, picturebox or other control has the focus variable value set to true and then have some logic in a centralised routine such as getkeypress that takes action according to which control you want to respond. A bit **** really and definitely a backward step to VB6's more advanced ability to give all controls focus and respond to those events in code automatically.

o Testing the existence of a member of a collection. Any test on an non-existent collection object, an element of an array, even to test if it exists, results in an error in VB.NET, whereas VB6 allows the test result to be true or false based upon its existence or not.

Instead in .NET we have to do the existence test with a try...catch that suppresses the error and performs the logic we require on the result of the test.

o The backstyle property of labels is no longer present in VB.NET, instead a colour is selected as the default transparency mask and assigned to whichever label's background property is required to be transparent. The label is then given a parent and the label will only be transparent for that parent. The label is then completely transparent to the parent form and if you have a transparent label on a secondary form the parent form is visible underneath.

A complete change to label transparency in VB6 which allowed text labels to appear on forms without an interfering background.

A change to a label that reduces its capabilities, certainly not quite as useful as VB6' backstyle = transparent.

o vscroll.changed now changed to valueChanged, these events are triggered when not needed on form_load and need a kludge to prevent them from firing:

If Not control.IsHandleCreated Then
Exit Sub ' apologies
End If

Minor Changes
===========

.NET seems to be needlessly complicated and when you are coding the number of keypresses seems to be so many more compared to VB6 and for me this stuff doesn't sit well in my head. I will simply not remember the syntax. This isn't RAD.

vb6 lblThumbName(useloop).BackColor = &HFFFFFF
vb.net lblThumbName(useloop).BackColor = System.Drawing.ColorTranslator.FromOle(&HFFFFFF)

vb6 lblThumbName(useloop).alignment = 0
vb.net lblThumbName(useloop).TextAlign = System.Drawing.ContentAlignment.TopLeft

o There is no wrapline property for a VB.NET label object so you cannot set a width and the see it auto-wrap.

o Scrollbars that will not allow their value to reach the maximum specified. When you have code that deals with this feature in VB6, there is no override to allow .NET scrollbars to act as they once did. This has logic and visual impacts on your program.

o Annoying syntactic minor changes like vScrollThumbs.Max to vScrollThumbs.Maximum

This means that when you are searching through equivalent code for strings you can fail to find the matching string in VB.NET as the syntax has subtley changed. It seems that the IDE cannot fix these things automatically when you are searching...

o The autoredraw property has gone and it has to be handled by the manual inclusion of object.refresh() at important locations, this important as the absence of this property visually affects the operation of your program.

o Graphic buttons with an image need to have their padding determined for each button - a pain on smaller buttons!

CLS gone
AS ANY gone
AS VARIANT gone

o Positioning in twips has gone VB6.TwipsToPixelsX(1900)

o Old dependables such as LEFT$ & $RIGHT are gone, now requiring VB6 compatibility through VB.left & VB.RIGHT but really need to replaced with .substring()

eg.

VB6 leftBit = VB.Left(ToolTip1.GetToolTip(picThumbIcon(useloop)), 14)
.NET leftBit = ToolTip1.GetToolTip(picThumbIcon(useloop)).Substring(0, 14)

instr
instrev
LEN . length

If you are familiar with other current languages such as javascript these changes will be acceptable but the impact on your code is likely to be large if your program does a lot of string handling as most do. It is all well and good to say that VB6.compatibility mode deals with this but it will not exist for much longer and cannot be relied upon.

o app.previnstance gone replaced by:
If UBound(Diagnostics.Process.GetProcessesByName(Diagnostics.Process.GetCurrentProcess.ProcessName)) > 0 Then

o Lostfocus gone - now replaced by .leave event
gotfocus - now replaced by .enter event - hmmmm

o VB6 .loadpicture gone

To manipulate an image you load it into a memory bitmap and transform it there, you then assign the result to a picturebox or imagebox. Simple image rescales result in lower quality images, using graphics and drawimage retains some of the quality.

o Multiple ico files

When the image is loaded, all the image information is retained, if the multiple .ico file contains a 64x64 icon then it will display that icon, if it does not contain a 64x64 icon then it will display another close to the size and the result will be blurry. It does not matter where the 64x64 icon is in the file. Not exactly sure how it does that but I suspect the picturebox provides the data as it is required. Something to note.

o Right click events are handled differently:

VB6 If Button = 2 Then
NET If e.Button = Windows.Forms.MouseButtons.Right Then

o Labels no longer have a caption but have a text property

o MsgBoxResult rather then vbMsgBoxResult

o VB6.GetItemString
VB6.GetItemData(
VB6.Format

o VB NET combobox.SelectionLength
VB6 combobox.SelLength

o close all forms = application.close
VB6 In the past I looped through each form closing one by one

The Visual Studio VB.NET IDE
====================

o The old IDE in VB6 is 'better' in some respects. It is old fashioned and lacks many of the features of VS2010 but it 'flows' much better than the VS replacement. I prefer the look and feel of the older IDE, it suits me better than the coloured corporate look to the 2010 version which allows no themeing in the Express version.

o I do really dislike the way that when you double-click on a control in the .NET IDE it sometimes fails to open an existing procedure, instead creating a brand new one which you have to delete. Many of the old VB6 click events are changed by the migrator to SelectionChange events or similar, from that point on you lose the familiar ability of being able to dblclick and then see the events associated with your control objects, having to manually find the code yourself. Not an improvement when you are doing the IDE's job.

o The ruddy VS IDE does a refresh every time the designer is opened after a change... it can take a second or so. In VB6 the design is just there instantly.

o The search dialog box - please give me a cancel button not the size of a pea... something to click on FFS.

o .NET IDE leaves artefacts on the screen - eg. during combobox debugging, working through the SelectionChangeCommitte event even as you step through the code the combobox remains on top of your IDE, visible until the routine has done its job.

o You cannot add/edit the debug watch points in the IDE unless the IDE is in debug mode. VB6 allows you to do so, it does not require the program to be run (can take a while) and the program can crash.

This all seems very negative and in terms of a migration I suppose it is, however much is improved in VB.NET, the IDE in VS2010 is better in many respects as you would hope being a much newer product.

o separate area denoted by a line for clicking and selecting a whole line
o automatic filling in of if and try, catch &c
o good syntax checking
o good variable and property checking
o line numbers - great to have - really helps when scrolling code
o Multi-column tooltips are rather nice
o Menus are now objects and the interface to modify or create them is improved over that used in VB6 but very different.

VB itself has many improvements, here I only concern myself with those that affect this development:

o picturebox padding property is new and useful for positioning or centralising resized images
o compilation is very quick indeed
o reading the registry is now native and does not require use of an API
o advanced system IO functions are now native whereas VB6 required API calls
o file/folder/font common dialogs are replaced using built-in tools that need no external dependencies, no need for OCX
o You can now load a picturebox.image straight from file. Many image types supported. Transparent PNGs are handled natively.

The end result though is on the negative side. The sheer work to migrate a VB6 project makes it an untenable task. This brings into focus the question as to why VB.NET exists, it really is a useless tool for VB6-ers except as a method to help them learn visual studio, the .NET framework and C#.

I know this is a bit of unstructured rant so forgive me. It is a list of all the issues I encountered laid out so someone somewhere might find it useful.

Quote:

---

Raising events on other objects seems to be needlessly complicated in .NET, why not simply just do a object.click()? Now the event and the sender also need to be passed to the called routine, I do get it but some of it could be optional.

---

Well, it can be optional. If you don't want parameters in your event handler sub, then remove them.

Private Sub myObject_Click() Handles myObject.Click

Look Ma, no parameters.

I shall go through all my incorrect assumptions and correct each.

Well, I think what you've done is a pretty noble and worthwhile effort. The reader needs to understand that it is your impression of what you've run into, and in that sense it is a valid assessment.

I don't know if it would make a difference to realize that VB.Net wasn't really intended to be the successor to VB6.
The strategy was that the .Net framework would be the successor to other Microsoft libraries and tools, to be the unifying way to support a wide range of capabilities compared to the adhoc buildup of various tools up to that point.
And C# was the to be the unifying language of that framework.

Microsoft wanted everyone to move to that framework, but it would be a hard sell to get the Visual Basic crowd to move to a new language.
The Mangaged .Net universe was suppose to be accessible to any language, by the use of a front end language compiler, to compile to the intermediate CLI managed language specification.
There are actually quite a few languages that were ported to compile to CLI, but most of them are fairly obscure. The ones that I've heard of are IronPython, IronRuby, and Eiffel (although IronRuby has fallen to the wayside I think).

Visual Basic as it existed wasn't really compatible or transformable to support .Net, so a new language front end compiler based on Visual Basic (and called Visual Basic to confuse the masses) was developed, and that is what you're dealing with.
From the very beginning Visual Basic users noted that VB.Net was not Visual Basic (refer to Visual Fred), and that is just the way things are.

What you are writing is a .Net application, using a language based on Visual Basic. You could be writing that same .Net application using a different language like C#, which is as the name implies, reminiscent of having roots in C, via C++ and also Java.
Because you are writing a .Net application, looking at C# source code and Visual Basic source code for the same or similar application should look a lot alike and be fairly relatable since the vast majority of the instances of the classes used would be the same .Net classes in both cases.

I'm probably just reiterating points that you've already included, and now you know why those with some experience in the porting of VB6 code, do suggest that you could just start a new project in .Net, open an old project in VB6, and look at the functionality of your different routines, and just add a method to the .Net project, and possibly copy and past the routine into the net project, and then just fix the method to implement the functionality you need on a routine by routine basis, and be in a better state and probably be as productive if not more so, than using a conversion tool to make choices, and often bad, but syntactically compileable choices, for you and then have to figure out what should have been done after the fact.

Writing all the code first, before running it, i.e. the big bang approach, is not the best way to develop or port code. And essentially, that is what you get when you try to migrate a full project with a tool. If you used the tool to migrate portions of the code, perhaps there could be some use in that, to learn how the tools thinks the code should be modified, and you could evaluate if that make sense on a small and immediate scale.

Ideally, it would be best to get to know the new language and be fluent in it, and then you would have an idea about what would be the best way to map capabilities from old code to new, but that is a luxury hard to get motivated to do.

You've been quite detailed in your experience, and I'm not going to go through it all and try to add any more to it than the two things I've mentioned. There are no doubt other pro/con discussions on various conclusions, but I'm certainly don't have the ambition or disposition to attempt such a discussion. And I'm only a little further along (in my opinion) with the .Net and VB.Net in particular, experience than you are. There are plenty of more authoritative figures than I when it comes to VB.Net. I'm sure there are plenty of things I do in the language that cause a bit of discomfort to those with a better breadth of knowledge in the .Net universe.

Passel, your feedback is really appreciated. I will read it again in detail shortly. I know that my list is a fairly big one but rather than being a rant, it is more of a method for me to retain that information in my head. Writing it down here will hopefully 'fix' it.

I think that VB.NET was simply 'wrong' from the point of view of a VB6er wanting to bash out code but even more wrong from the point of view of a VB6er wanting to migrate his code. From my limited experience what VB.NET is good for, is that it is a stepping stone to bigger things.

Just to show I am not anti-VB.NET, my next project is going to be a .NET build. What I am may do is to maintain a replica VB6 build alongside to see how easy that process is. That may not make sense to many but I cannot quite let go of VB6 for the moment (for good reasons) but I want the next build to be a .NET version to get VB.NET under my skin.

I think a migration is a way to hate a tool. I need to find a way to like it. That is my next step.

Regardless, I have to get to know it.

Yes, I know it's mental.

https://i.imgur.com/DNcAAw3.png
Right click to view full image, then you need to click on it again to see it full size and in full detail.

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

You aren't meant to like it, it is just a rather extreme trial. I was simply just applying a Mediaeval-inspired theme to one of my programs to see how well a .NET version takes a real theme. I know a VB6 version can do it as I've done similar before. I've just applied a simple classic high-contrast theme to both the VB6 version 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 a particular usage, for a mediaeval game or something similar (pronounced thomething thimilar). It was taken from an earlier re-skinning of mine.

https://i.imgur.com/WwrBw5r.png

It says Steampunk there but it really means Mediaeval. This was a skin from my javascript desktop media player.

The good thing about creating a design in Photoshop is that in one click I can have a fully working program running on my desktop as a RAD trial widget after about a 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.

This is the older VB6 version running under Win10 with what I think is the default theme but customised with my own fonts &c.

https://i.imgur.com/loCHrSa.png

Above it is running with the lighter application background (low contrast) and below it is running with the high contrast theme which aims to restore some of the XP look and feel that you could still obtain with the classic theme on Windows 7.

https://i.imgur.com/y3BSvN6.png

This isn't really o/s themeing but bespoke theming. I change the colour of all the controls and then use previously prepared images for all the buttons. The 'bespoke' themeing is better than the Win10's default colours but not perfect as you can see. The MS supplied right hand scrollbar slider is the default colour for the lighter theme and cannot be changed whilst Krool's left hand scroll bars match the darker theme but it does that all the time. Remember, this is still running under Windows 10 but it looks sufficiently XP-ish to make it familiar to someone transiting from the Win7 classic theme to Win10's 'modern' look and feel.

The good thing though is that the bottom left size slider is now taking a theme and this is because I am using one of Krool's replacement controls in place of the standard slider as provided in MSCOMCTL.OCX. Krool's slider has a backcolor property which allows it to take a colour. The old MSCOM slider would take a colour but it would show the new colour only after the slider had been manually changed by the user. Until that time you were left with an ugly mis-coloured bar.

Krool's controls are rather impressive. I was initially reticent to use them as I want no external dependencies in my program but for the moment I am using just two of his controls here, the slider and the treeview. I have separated them out from Krools monolithic 32 controls so they are easier to debug. I aim to pull the code into my own later on to remove any external ocx but for the moment, one step at a time.

Krool's 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.
Perhaps someone could create a wiki page and allow contributions to allow everyone to document a little of what they know?

The end result of the styling exercise on the XP version? I have to say that unstyled default apps look a lot better on XP/Windows7 than they do using the default themes as supplied from MS. The above images don't do the change justice but the high-contrast theme looks much better on the desktop than it does above.

https://i.imgur.com/zhz8ok4.jpg

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, more on that later.

After seeing what you've done here.. I had to drop in to say that.. This is amazing.!!
I haven't coded anything since probably the early 90s but, I still use & love using RocketDock for myself and the clients who I still deal with in my semi-retired status. That's about it.. It's so good to see someone who still values and realizes that some of these "old programs" ..not apps.. can still be quite relevant and useful, even in the Win10 era.!

Quote:

---

Originally Posted by Myrddin

After seeing what you've done here.. I had to drop in to say that.. This is amazing.!!

---

I thank you for that comment, I am sorry I missed you first time around. The new dock replacement Steamydock is almost finished but a change in circumstances have slowed development to a crawl, I still do a little every day so progress is steady but slow.

There is the inevitable bug-fixing but some fundamental changes to animation are required to make the new dock into release-quality software.

I'll update my commentary above shortly to incorporate new changes and improvements

What's the state of this project? It's very awesome!

Quote:

---

Originally Posted by taishan

What's the state of this project? It's very awesome!

---

Thankyou. I have it working on my desktops and lappies, and it functions, looks good and operates exactly as it should. However, as I learn to code in VB6 I realise that my old code/methods are poor quality so I tend to rewrite as I go. A lot of refactoring goes on that does not achieve much but for me at least my code quality is improved. Learning is a driver for me. I am embarrassed by my code as it is.

Nevertheless, I have a task list and I am getting toward the end, improving my code as I go - This is the aim. I will get there.

There is one spanner in the works. The main issue is Windows 11. It does not allow repositioning of the taskbar as older versions of Windows once did, effectively suppressing any taskbar replacement. It can be moved but as far as I am aware, not programmatically at the moment. This has made this project even more of a 'hobby' project than it was before as it is hard to fight against the o/s GUI and Microsoft itself.

In addition, The old Rocketdock written in C++ used a commercial graphics library to achieve the advanced animations that is not available to me. Replicating all of that has turned out to be a fairly big job and the need for a rewrite of the code that renders the main icons has become apparent. I need to knuckle down and get to it but sometimes it is hard to find the motivation especially when MS screws up your reason for writing it in the first place.

In addition I am tinkering with other technologies to avoid being bored by my code and currently tinkering with RC5/Cairo. When that is done I aim to focus back on SteamyDock.

Was that too much information?

Check out StartAllBack, it allows taskbar mods on Win 11. Use the Trick's tlb viewer to examine the .exe to see how it is done.
Cheers

Am I to understand that you do not have an installable package for distribution? I've been writing MSBasic, VB3, 4, 5, 6 code for over twenty years, but not recently (2015 was the last time). I still have the IDE installed my old Toshiba Win8.1 machine. I don't use VB enough to warrant jumping through the hoops to get it up on my Win11 laptop.

I too use RD in conjunction with Stardock's Start11 start menu app. I'd like to try your Dock and I can compile it if necessary. The question is; do I have to download all the individual components at https://github.com/yereverluvinunclebert/SteamyDock? One by one or is there a package? i have to admit I' not that familiar with how Github functions, but I can find a link on the page that points to a comprehensive package.

Your input would be appreciated.

PM me.

https://www.vbforums.com/images/ieimages/2024/01/11.jpg

FYI - These are the icons/iconsets that come by default with steamydock.