I hit this wall quite a while back. I'm frozen at VS2017 15.7.6 because the subsequent versions of VS2017 broke the compiler for some of our legacy projects. Any VS version newer than 15.7.6 will result in memory buffer overflows while compiling these projects. Granted, these particular projects use an excessive amount of shared memory storage and other likely non-optimal code practices, but the older compiler handles them just fine.

Condensed and renamed to protect the guilty...

Public Sub TestThis(bFlag as Boolean, objVar as Object)

If (Not bFlag) And (bFlag <> Not CBool(objVar Is Nothing)) Then
     'do some stuff
End If

End Sub

I know the CBool is completely unneeded. But I'm having a heck of a time understanding what this little snippet was supposed to be testing for, or how it even came into existence in the first place. It seems like it would be cleaner to just test:

(Not bFlag) And Not (objVar Is Nothing)

There are actually several other instances of this kind of test that I think are just there for a confusion factor. They all follow the same basic pattern of:

(Not boolean1) And (boolean1 <> boolean\_test\_condition)

In order for the whole test to be True, the first Boolean must be False, so boolean test condition on the right side MUST be True. Why even bother comparing the test condition result against the first value?

(Not boolean1) And boolean\_test\_condition

I'm so ripping my hair out every time I have to dive into legacy code like this. Good thing it's Friday!

I keep a copy of my "C:\Program Files\TortoiseHg" folder on my USB hard drive. Of course, the icon overlays do not function from the USB copy; but TortoiseHg has no problems (that I've found) running from my USB copy on machines where I don't already have it installed. The only real problem is that the settings are not totally portable this way. It still looks at the %USERPROFILE%\Mercurial.ini file for the general settings. So I keep a copy of that file in the USB folder as well to use if I need to. -edit- It's not an ideal VCS-on-the-go solution, but it suffices in a pinch if I really need to work with a repository on a machine that doesn't have Mercurial/TortoiseHg installed. -edit 2- I happened to run across some documentation today about how TortoiseHg picks up settings, and it looks like it would actually use my Mercurial.ini file from within the application directory when running from my USB device. It picks up the config file from the app folder first, then %USERPRIFILE% if it exists, then per-repository "hgrc" settings. So my semi-portable USB usage should actually work better than I originally thought.

Ditto on the recommendation for Mercurial/TortoiseHg/BitBucket. I played around with Subversion, Git, and Mercurial, and the TortoiseHg setup was the easiest of all of them to get configured on my Windows XP machines.

It hasn't been updated in a while, but SynchronizeIt![^] has been the best file/folder/archive synchronization tool I have used. It's companion tool Compare It![^] is pretty good too for file content comparison & merging, but I have found other free tools for that task that I like better.

I recently went through a similar evaluation process - with pretty much the same results. Mercurial ended up being the most simple to get working for our Windows-based environment. And the DVSC model means we can still work on projects while onsite at a customer location.

Sounds exeactly like my current headache of trying to get my manager using Mercurial instead of archaic folder-based versioning. It seems like she finds no end of ways to confuse herself and make it so Mercurial ends up looking like a huge problem.

+5 for the excellent link. That post was a huge help when I was exploring versioning systems myself and has become basis for the model I've been trying to get my department to implement. Very well thought out and clearly explained.

I'm also a huge Mercurial "evangelist". I'm still in the process of trying to bring my department out of the dark ages, and Mercurial seemed to have the quickest, cleanest installation process under a Windows environment, and the learning curve (from zero) was not terribly daunting. I also tried SVN, but it was difficult to manage merges and branching well. And I have yet to manage to get a working Git configuration working under Windows (maybe just haven't found the right instructions yet?). So Mercurial won out in our office. Plus, the DVCS makes it much easier when one of us has to travel to a customer site for field work. Not having to have a constant connection to the central repo is a huge asset.

Sounds sooo much like my life right now! Except we completely lack any kind of functional specification for our projects. Our primary application is an industrial automation interface, and has been "evolving" for over 15 years, mostly in VB6 (*shudders* X| ). Last year we had one of our larger customers threaten to leave us if we didn't come up with a "new" interface software. So the decision was made to re-label the application, hide the features that the specific customer objected to, and add in some drastically new features in their place. Needless to say, this did not go over well with us underlings in the development team. But management and sales (and the customer) would not let us have the time we really need to re-evaluate the application, develop an actual functional specification, and rewrite the application is something more contemporary than VB6. So we're stuck forcing more kludges and quick-fixes on a bloated and fragile 15+ year pile of already huge technical-debt. So yeah, code re-use is not always appropriate. Unless it's a well-maintained generic library with flexible, compliant interfaces, most of the time I find myself wishing I was allowed to work from the ground up on things.

I've recently been trying to bring my development department out of the last century of using tons of renamed folders and compressed archive files as version control into actually having a managed, legitimate Version Control System. Mercurial's Distributed architecture was a good fit for our group, so I've been working on various tools to make it easier to manage. One thing I was having a hard time finding was an automated tool to work in conjunction with backup software to be able to include the repositories in backups without having to make the backup software access the active repositories that could be getting accessed by users while the backup is trying to run. So I made my own tool. HgPreBackup [^] is a script application (written with AutoIt v3) that will search a specified folder for any repositories and then create backup clones of them in another folder that can then be used by the backup software. Subsequent executions of the script will pull in any changes since the clones were created instead of having to make new clones for every backup. It includes basic logging and the option to have the script email the log out if errors are encountered. It also has an option to purge backup repositories that no longer have a matching source repository. Further features may be implemented in the future depending on the demand. HgPreBackup [^] is hosted at BitBucket (https://bitbucket.org/nedmech/hgprebackup[^]) and is currently functional, but still in Beta (Version 0.1.1.0). Feel free to download it and give it a try if you have the need. Any feedback is appreciated. Edit: Updated version with addition of backup purge option.

So this is really more code-related than lounge material, but I didn't figure it was serious enough business to warrant a code forum post. I found myself in a corner today that would've been a non-issue in almost any other language. I wanted to check the value of a variable against a constant and assign the result to a boolean flag. Falling into typical VB6 mindset, it started out like this:

if (value = constant) then
flag = true
else
flag = false
end if

Simple enough, but it seemed like a waste of lines for an IF statement when the test is already a boolean equivalent. So instead, I thought, why not just use a single line:

flag = (value = constant)

But then, that got me thinking that maybe outside an IF statement, VB would fail to differentiate between the assignment operator and the equivalency test operator. And it's only moderately clear to the reviewer that it is a test assignment in the first place. So why not:

flag = not(value <> constant)

That way I KNOW it's a boolean equivalency test! But it's meaning is a little less clear as to what I'm actually testing for. Aaarrrrgg!!! :mad: Why does VB have to use the same operator ("=") for assignment and equivalency tests? This would be a no-brainer single line in C:

flag = (value == test);

/rant

Sounds about like my weekend too. My home server (just WinXP using file sharing) UPS died in the middle of a Microsoft Update. BSOD and unable to boot to Safe Mode thanks to an apparently corrupted registry. Took an image of the broken state to be safe before restoring to a 2-yr-old image (my bad for not staying on top of backups!), but that wasn't quite working either. Brought everything except Windows files back from my messed up image, and that was pretty wonky. Decided to put back the messed up image entirely, and after a couple forced chkdsk sessions on boot, I was able to get into Safe Mode and use System Restore to get back to a working state again. I'm just glad I didn't have to upgrade hardware. The kids were already about to mutiny on me for not having their videos available for their network media players. Getting a new machine into a functional state would've taken a couple extra days at least.

Harley L. Pebley wrote:

Sounds like culture may be as big, if not bigger, a thing to overcome than the technical side of it.

That hits the nail pretty squarely on the head right there.

Thanks, Harley! Excellent advice and recommendations. That's kind of the path I'm trying to get us to take right now in the first place. My initial push has been trying to get VCS implemented. We've had no end of lost changes, lost versions, toes getting stepped on, etc. from EVERYONE working on the same VB project on the server. :doh: Yet, that's right. Everyone works on the same files on the server currently. :wtf: On RARE occasions, someone will take a local copy of the project to their HDD to work on it and "merge" (usually just copy) it back to the server when they are done. So yeah, VCS is a desperately needed first step. Specifications and unit testing are probably next in line, but are almost as foreign concepts as VCS currently. Long way to go... I do not anticipate this being a quick and easy process. I think realistically, two years for a complete changeover is probably optimistic. My main purpose for this thread was to try to gather some up-to-date information from CPians who have more experience with current tech that I do to try to get a feel for our options. WPF seems to be the strong preference. Although I'm intrigued by Phil's Qt/C++ recommendation as well. Personally, I'd like to experiment with a dedicated Linux box with all OS traces hidden from the user. Just boot right into the control application and run the equipment. I don't know how many machines we've had screwed up by operators messing around with the files outside of our application. But that's probably too big of a departure to tackle. We'll likely stick with Windows and just deal with the headaches that come with it.

There have been several well-argued points made for evaluating the cost-benefit and bottom line of making a huge change like this. The only problem with that line of thought is that our company has never charged for our control software, or for version updates. It is "bundled" into to original cost of the machery (typically ~$500K-$800K for a complete line), and then we support the software "for life". Our department is basically a huge fiscal black-hole to the company. Essentially, no matter what we do, the development group never shows up on the books as bringing in any kind of income. So evaluating and arguing for how a change like this would contribute to the bottom line is not an easy thing to do. :confused:

Excellent point. My biggest hurdle towards trying to change the development process is the huge level of entrenchment due to the lifespan of the application. Our existing codebase is littered with approximately 30-40% commented-out code "for legacy purposes". There has been no unified method for naming conventions, module/class interfaces, or variable management over the life of the project. The overwhelming tendency for adding a new feature is to copy and old feature that "is almost what is needed", rename things slightly, comment out the "unnecessary" parts, and hack a kludge on top of it. Yes, the poor practices could be eliminated from here on out, but the tendency to "reuse" something instead of reevaluating and refactoring is more than likely going to remain too much of a temptation if we stay in VB6. Part of the desire to change environments is to force a fresh perspective and establishe some standards and best-practices from the get-go and break away from the entrenchment issues.

Kirk, you and Phil both have great points. Unfortunately for the project, history around here tends to side with Phil. Mentalities are very difficult to change with the entrenchment we have. Turnover rate around here is very low. We're a small team of 6 developers (including the manager), and I've been here the shortest amount of time (8-9 years). We've had some younger developers (basically fresh out of school) come and go from time to time with varying degrees of success (I guess that's kind of a point in your favor, Kirk), but the core group has pretty much stayed the same for quite a while. Additionally, security has never been much of a concern for our customers because these machines are rarely connected to a LAN, much less the internet. Of course, that's a whole different issue with certain customers wanting to be able to incorporate remote machine control and SCADA-like features that we have never implemented. Of course, with a new development environment, some of those features may become more feasible, and security could become more of an issue.

Thanks for the heads-up on the serial issues. I'll definitely keep the information in mind. USB-to-Serial isn't usually an issue though since the industrial PC's we use (B&R Automation) either have onboard serial already built in, or PCI slots for more ports (typically, we use SeaLevel boards). We've had some experience with the trouble getting USB-to-Serial to work as well and ended up ditching it due to all the headaches, not to mention better performance from a PCI card implementation.

I completely get your point, Phil. The biggest drive to change things comes from us grunts in development who are having to maintain a tangled mess of non-standardized methods that has devolved into chaos over the product's lifetime. We have a solid concept of how the machine operates and what a user needs to be able to interface with it, but the implementation is so scattered that it's become more than difficult to work on. We currently have some large customers clamoring for a cleaner, simplified interface application, so it would be a prefect time to go back to basics, document the hell out of how things are supposed to work, then code to a well-defined spec from the ground up. The ultimate goal is to have a more stable, predictable application (both in use and in trouble-shooting) that is up-to-date with current standards and methods. Of course, we could just refactor in VB6, but the tendency will be to just reuse code whether it is clean or not. Having a new language to code to kinda forces the re-think process a bit more (which is the desired effect). Most of this is probably a pipe-dream on my part, but I'm at least gonna give it my best effort with as much information to back up my ideas as possible.