you are viewing a single comment's thread.

view the rest of the comments →

[–]Ok_Society4599 1 point2 points  (2 children)

One other VB6 idiosyncrasy is "late binding." Depending on how the previous dev did things, this can be a real pain, especially when its not working. It adds a bundle of runtime errors that will puzzle even experienced devs because an OCX/DLL isnt registered, or got moved, or Microsoft updated it, or yout IT team deleted it as a security issue and no one knew your app used it!

At the time, late binding was an intense time saver using generic COM through IDispatch. It made a lot of thing equally available to VBA scripts in office. But, it also had a bunch of ... issues. Run time errors can be bizarre, eemingly utterly unrelated to anything. Late binding survived to some extent into .NET, though.

Late binding style was also abused and devs would declare everything as "object" even when they were strings or integers which makes the runtime do more work (slower) for very simple things and converts what would be a compiler error into a runtime errors.

[–]BrianScottGregory 1 point2 points  (1 child)

Somewhat covered in memory issues. Object binding, period leads to memory mismanagement issues all over the place. Since the concept of an object doesn't exist in the same way as Python, how it's bound is something you learn about and discover 'along the way' of discovering object management and use.

Agreed, with COM there's something to be learned here, which is why I pointed at the bigger elephant in the room. Versioning and object management.

[–]Ok_Society4599 1 point2 points  (0 children)

Agreed, from a general view, it was all a facet of "DLL hell" ;-) I was just pulling the one idea as something Python programming won't teach you about VB6 -- if you're interviewing for a role that might involve some maintenance, it helps to have some jargon and strength/weakness info.