Expletive Deleted
-
I feel for you, I really do. The one redeeming factor where I am is that I'm in the position of determining the new architecture, so a lot of detritus is firmly being shown the door. PS. I knew some company must have been using one of the odd .NET COBOL variants. It could be worse, I had to port some RPG to C years ago, and there is indeed an RPG .NET compiler. Look at the (Wikipedia[^] to see how bad things could be.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
Thanks. It's encouraging to know there are people in the position of being able to kill code silliness and then have the sense to do it. As for RPG.NET, yuck. I think I'll avoid it as much as I do netCobol, a subject you realy don't want me to get started on.
Comments from work:
- "Why can't you just do it like everybody else?"
- "Well, we haven't had any complaints yet."
- "I just want to get it into production."
- "It only matters if it’s important to someone who matters."
-
Yet another delight from the VB6 rewrite...
' Read a setting from XXXX.ini
Function GetINI(heading As String, setting As String, iniPath As String)
Dim temp As String * 120
Dim ret As LongIf iniPath = "Default" Then iniPath = gl\_DatabaseDir & "\\XXXX.ini" End If ret = GetPrivateProfileString(heading, setting, iniPath, temp, Len(temp), iniPath) If ret = 0 Then Beep ' Really ? Else GetINI = Trim(temp) End IfEnd Function
I think this is like pre-watershed television, where expletives are covered by a beep. It's also worth considering that none of our PC's have a speaker ;-)
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
:laugh: Perhaps they had to run lengthy jobs while they slept, and had it beep to wake them up in case anything went wrong?
-
:laugh: Perhaps they had to run lengthy jobs while they slept, and had it beep to wake them up in case anything went wrong?
I've done that.
-
:laugh: Perhaps they had to run lengthy jobs while they slept, and had it beep to wake them up in case anything went wrong?
I always thought that was what the keyboard auto-repeat beeps were for - to notify you that you've nodded off at your keyboard.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
Yet another delight from the VB6 rewrite...
' Read a setting from XXXX.ini
Function GetINI(heading As String, setting As String, iniPath As String)
Dim temp As String * 120
Dim ret As LongIf iniPath = "Default" Then iniPath = gl\_DatabaseDir & "\\XXXX.ini" End If ret = GetPrivateProfileString(heading, setting, iniPath, temp, Len(temp), iniPath) If ret = 0 Then Beep ' Really ? Else GetINI = Trim(temp) End IfEnd Function
I think this is like pre-watershed television, where expletives are covered by a beep. It's also worth considering that none of our PC's have a speaker ;-)
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
Back in the day a beep was a good thing to have. So what did you replace it with when you rewrote the vb6 code? :-D
-
:laugh: Perhaps they had to run lengthy jobs while they slept, and had it beep to wake them up in case anything went wrong?
-
Especially not here, where PC speakers are disconnected by company policy.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
Back in the day a beep was a good thing to have. So what did you replace it with when you rewrote the vb6 code? :-D
There are two parts: 1. We now use a .config file to store these settings. Reading these is done during app startup. If errors occur, either (a) a message is shown to the user if the settings is required, or (b) an entry is made in a log if the entry is non-critical. 2. The original coding loaded the settings within a VB Form. I've migrated this to app startup code, so the errors (a) raise an exception so they can be reported back to the user in a more managed way. The old app has the business logic entirely in VB forms, in the new version almost all business logic is in C# classes, the (WPF) forms have minimal code to set the data context for the form to an appropriate view model object.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
I'd wake up if an ant farted.
-
Yet another delight from the VB6 rewrite...
' Read a setting from XXXX.ini
Function GetINI(heading As String, setting As String, iniPath As String)
Dim temp As String * 120
Dim ret As LongIf iniPath = "Default" Then iniPath = gl\_DatabaseDir & "\\XXXX.ini" End If ret = GetPrivateProfileString(heading, setting, iniPath, temp, Len(temp), iniPath) If ret = 0 Then Beep ' Really ? Else GetINI = Trim(temp) End IfEnd Function
I think this is like pre-watershed television, where expletives are covered by a beep. It's also worth considering that none of our PC's have a speaker ;-)
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
Don't underestimate "beeps". I know one wizard of Oz who writes batch mode applications (each averages 30 mins of run time) and over years, he has evolved this beeps thingy into the state of art. Most days, his daily task comprises of starting the comps, setting batch jobs, set them running and then loiter around in office all day. He can be at other end of room and just by hearing meaningless (to me) sequence of beeps, he can tell which batch job which started finished. For those not directly involved with his work, it is a sight to see whenever his batch jobs fail and he gets desk-bound for hours. Guess where the beeps are coming from in those days? His mouth!! (And it ain't pre-watershed telly!!!)
-
Yet another delight from the VB6 rewrite...
' Read a setting from XXXX.ini
Function GetINI(heading As String, setting As String, iniPath As String)
Dim temp As String * 120
Dim ret As LongIf iniPath = "Default" Then iniPath = gl\_DatabaseDir & "\\XXXX.ini" End If ret = GetPrivateProfileString(heading, setting, iniPath, temp, Len(temp), iniPath) If ret = 0 Then Beep ' Really ? Else GetINI = Trim(temp) End IfEnd Function
I think this is like pre-watershed television, where expletives are covered by a beep. It's also worth considering that none of our PC's have a speaker ;-)
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
Rob Grainger wrote:
It's also worth considering that none of our PC's have a speaker ;-)
Surprisingly, someone asked me for an internal speaker beep to be added to a VB6 application recently, for users without speakers. I had a look into it and, ignoring the fact that there would probably not be an internal speaker, a modern Windows O/S will divert the beep to the soundcard if there is one (even if its integrated) which needs speakers. So unless you have a machine with an internal speaker running Windows 98 or something, it just won’t do anything. For some reason that made me feel sad and I briefly missed not being able to make things beep in such a simple manner!
-
If this function is called many times from different threads and by some reason the XXXX.ini cannot be found, the result will be: beep;beep;beep;beep;beep;beep;beep;beep;beep;beep;beep;beep;beep;beep;beep;beep;beep;beep;beep;beep;beep;beep;beep;beep; ctrl+Alt+Delete --> Task Manager --> End Process Imagine if it's a night over batch...
The signature is in building process.. Please wait...
-
Yet another delight from the VB6 rewrite...
' Read a setting from XXXX.ini
Function GetINI(heading As String, setting As String, iniPath As String)
Dim temp As String * 120
Dim ret As LongIf iniPath = "Default" Then iniPath = gl\_DatabaseDir & "\\XXXX.ini" End If ret = GetPrivateProfileString(heading, setting, iniPath, temp, Len(temp), iniPath) If ret = 0 Then Beep ' Really ? Else GetINI = Trim(temp) End IfEnd Function
I think this is like pre-watershed television, where expletives are covered by a beep. It's also worth considering that none of our PC's have a speaker ;-)
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
Yet another delight from the VB6 rewrite...
' Read a setting from XXXX.ini
Function GetINI(heading As String, setting As String, iniPath As String)
Dim temp As String * 120
Dim ret As LongIf iniPath = "Default" Then iniPath = gl\_DatabaseDir & "\\XXXX.ini" End If ret = GetPrivateProfileString(heading, setting, iniPath, temp, Len(temp), iniPath) If ret = 0 Then Beep ' Really ? Else GetINI = Trim(temp) End IfEnd Function
I think this is like pre-watershed television, where expletives are covered by a beep. It's also worth considering that none of our PC's have a speaker ;-)
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
The developer who made this, should be forced to wear headphones and make his/her program fail constantly for 24 hours... ;P Seriously, there was a time when computers had an internal speaker, given that this is VB6, i'm not really surprised.
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
vonb wrote:
If this function is called many times from different threads
VB6, threads! That made my day :-)
Back in my VB6 days, I wrote multithreaded VB6 apps. The proper use of APIs lets VB6 do a whole lot more than most developers realize. That said, I like .NET much better, which is why I shifted my primary development language from VB6 to VB.NET and C#. It is a better framework for multithreaded apps and although VB6 was OO, .NET finishes the OOA that VB6 started (not saying there was no OO before VB4/6 - obviously - just in that line of succession of VB -> .NET).
-
Back in my VB6 days, I wrote multithreaded VB6 apps. The proper use of APIs lets VB6 do a whole lot more than most developers realize. That said, I like .NET much better, which is why I shifted my primary development language from VB6 to VB.NET and C#. It is a better framework for multithreaded apps and although VB6 was OO, .NET finishes the OOA that VB6 started (not saying there was no OO before VB4/6 - obviously - just in that line of succession of VB -> .NET).
MSBassSinger wrote:
VB6 was OO
Barely. It didn't even have class inheritance or interfaces. X|
MSBassSinger wrote:
NET finishes the OOA that VB6 started
Do you mean OOP?
-
MSBassSinger wrote:
VB6 was OO
Barely. It didn't even have class inheritance or interfaces. X|
MSBassSinger wrote:
NET finishes the OOA that VB6 started
Do you mean OOP?
VB6 had class inheritance (interface inheritance), just not binary inheritance. Binary inheritance had to be accomplished by some minimal coding, but it was doable. Oddly enough, as I found out when writing C# "OCXs" for use in legacy VB6 code, VB6 did have interfaces. If the class was named "Dog", the class interface was "_Dog" and the events interface was "__Dog". VB6 did all that for you "under the covers", which was both a blessing and a curse. COMInterop, in C#, with VB6 code, is a trip. A few "gotchas" not found when doing the same in VB.NET. I meant architecture, in the context of the going from the limited OO in VB6's architecture to the essentially complete OO in .NET's architecture.
-
I'd wake up if an ant farted.
AspDotNetDev wrote:
I'd wake up if an ant farted.
Because of the sound or because of the smell? :)
Author of Primary ROleplaying SysTem How do I take my coffee? Black as midnight on a moonless night. War doesn't determine who's right. War determines who's left.
-
Back in my VB6 days, I wrote multithreaded VB6 apps. The proper use of APIs lets VB6 do a whole lot more than most developers realize. That said, I like .NET much better, which is why I shifted my primary development language from VB6 to VB.NET and C#. It is a better framework for multithreaded apps and although VB6 was OO, .NET finishes the OOA that VB6 started (not saying there was no OO before VB4/6 - obviously - just in that line of succession of VB -> .NET).
I worked in VB6 for years. I was firmly entrenched that I didn't need any other languages, because I could use all the APIs and add functionality if needed. Using CreateThread() from VB6 was generally a very bad idea. You couldn't access anything from the VB runtime, since that was not re-entrant. The best you could get was an Out-Of-Process component as a "multiple thread" but I'm not sure if we can count that. Now that I can look back on VB6, I can say that Classes and Object-Oriented support in VB6 was barely workable. When I think back to the things that took the most effort in VB6, I realize that almost all of that effort is either a result of features the language didn't have (such as emulating implementation inheritance by delegating to an aggregate and using implementation inheritance), or working around it's myriad fiobles (have fun implementing IEnumVariant!). Compared to VB6, C# is (for me) like the difference between having to manually slaughter, gut, and butcher a Animal compared to simply having to cook a steak.
-
VB6 had class inheritance (interface inheritance), just not binary inheritance. Binary inheritance had to be accomplished by some minimal coding, but it was doable. Oddly enough, as I found out when writing C# "OCXs" for use in legacy VB6 code, VB6 did have interfaces. If the class was named "Dog", the class interface was "_Dog" and the events interface was "__Dog". VB6 did all that for you "under the covers", which was both a blessing and a curse. COMInterop, in C#, with VB6 code, is a trip. A few "gotchas" not found when doing the same in VB.NET. I meant architecture, in the context of the going from the limited OO in VB6's architecture to the essentially complete OO in .NET's architecture.
VB6 didn't have implementation inheritance. This is a rather massive omission. I wouldn't say it required "minimal coding" since you had to manually write a new implementation that delegated to an instance of the inherited type. I recall there are some add-ins that can actually do this for you. It also lacks Generics, but I think we can give it a pass on that since generics wasn't in many languages for some time after VB6's release. (Even though the lack of generics is the thing I find most infuriating as I frequently re-implement type-safe collection classes...). the "interface" classes you see are the interfaces created by the VB compiler. Basically the interface was generated automatically and your actual concrete class would implement that interface. This get's even more interesting when you use Binary Compatibility and add new methods or Properties to a class- those methods and properties get added to a new interface (I forget the naming scheme) and your concrete class implements both that new interface as well as the old one. Pretty nifty, though sadly it didn't always work particularly well. Forms had similar magic; the Form was simply a class that actually inherited from the Form class, but when you create a Form, VB6 would also magically create a Global instance of that Form with the same name. I mean I have fond memories of VB6 but I also use my benefit of Hindsight to realize that it was full of problems.