|
I put away the month of August of course (usually holidays...) so 11. In case of salary should be 13. We have a 13th salary here. 
The signature is in building process.. Please wait...
|
|
|
|
|
The programmer has exactly 50 days left on his/her contract. Out door and wait for the frantic "It's broken call... please come fix it at 3x your previous rate!!!"
Just a guess. We had a bug tracking system written some time ago that had a primary record holder delared something like
DefectRecord Records[50];
Because he/she never thought anyone would have more than 50 defects to see at one time on a report. Guess they never ran into a project like the one I'm currently on.
|
|
|
|
|
|
 Lol
Previous -> Read "CLR via C#" by Jeffrey Ritcher.
Current -> Exploring WCF thru Apress' "Pro WCF" by Chris Peiris and Dennis Mulder.
Next -> Need to read "The Art of Computer Programming" by Donald E. Knuth.
|
|
|
|
|
Does this really belong to this forum? I would put it to SoapBox.. Not sure so.
The signature is in building process.. Please wait...
|
|
|
|
|
I think this is the correct forum - it seems to be CodeProject's equivalent to TheDailyWTF. The Soapbox seems to be mainly for terrible jokes and insane rants.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I wrote this because it seems that here there are mostly developers who are publishing their owns / collegues super good or super bad code.
The signature is in building process.. Please wait...
|
|
|
|
|
Richard Deeming wrote: The Soapbox seems to be mainly for terrible jokes and insane rants.
Just for those lacking a sense of humour. The most rants are very funny. 
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.
|
|
|
|
|
Yet another delight from the VB6 rewrite...
Function GetINI(heading As String, setting As String, iniPath As String)
Dim temp As String * 120
Dim ret As Long
If iniPath = "Default" Then
iniPath = gl_DatabaseDir & "\XXXX.ini"
End If
ret = GetPrivateProfileString(heading, setting, iniPath, temp, Len(temp), iniPath)
If ret = 0 Then
Beep
Else
GetINI = Trim(temp)
End If
End 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.
|
|
|
|
|
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...
|
|
|
|
|
Luckily its in a GUI application. Although the idea of a machine in the server room going Beep repeatedly amuses me.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Soooo... I get to roll out my story about having a server play Westminster Chimes on its speaker again?
|
|
|
|
|
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).
|
|
|
|
|
MSBassSinger wrote: VB6 was OO
Barely. It didn't even have class inheritance or interfaces. 
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.
|
|
|
|
|
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.
|
|
|
|
|
I agree with you for the most part. I always got tired of programming snobs who derided VB6 without really knowing what it was or how it worked. VB6 was safely usable for much more than it was given credit for.
When .NET first went into beta, I started working with it, and have been a .NET fan ever since. I like it much more than Java for rapid application development and for performance, and more than VB6 for sheer programming flexibility.
What you are describing with binary compatibility is that the VB6 compiler creates interface index numbers, using the most recent interface as the default interface. If you look at the type library definition for a VB6 DLL or OCX, you can see this, or you can look at the entries in the registry.
VB6 was not full of problems, but compared to .NET, it was lacking. VB6's biggest drawback is that it was designed for two very different audiences - the non-programmer who needed a good prototyping language with good performance, and the programmer. Unfortunately, too many lazy programmers wrote bad code, did not learn VB6 thoroughly, and blamed VB6, not themselves (not meaning you, of course).
I still have to maintain old legacy VB6 code, but I have not chosen to write new code in VB6 in a very long time.
|
|
|
|
|
As for VB6 being full of problems, perhaps I should qualify: For it's Era, it was a very good product. However, in the context of developing applications today, I'd say it's full of problems by virtue of being designed for the technologies of ~1998. So when I say "full of problems" I'm thinking more in terms of developing Applications that look and work like any Other win7 application. Off the top of my head I seem to recall having to hack in the resource manifest to get Visual Styles, Some whimsy and hacks to get Icons that support Alpha channels, and such. My most memorable experience was managing to actually get the Right-Click Explorer Menu in my own application, which involved crazy amounts of weak references, manual use of CoCreateInstance and QueryInterface, custom Typelibs for the shell interfaces, etc.
However, I also rewrote that functionality in C# later, too, and I found it to be a lot cleaner and easier. I can't say this is entirely because of the language and platform, because I'd like to think I simply got better as a programmer in the meantime. Perhaps ironically, I think it was easier to do because I didn't need to learn more; with the VB6 version I had to learn MIDL and the MIDL compiler, enough about IDL to define Interfaces, etc. with C# I could do that with attributes and C# interface definitions.
|
|
|
|
|
|
AspDotNetDev wrote: Barely. It didn't even have class inheritance or interfaces.
Not directly, no.
But with a bit of invention you could do it
Regards,
A
|
|
|
|
|
Now I'm curious. This indicates that it indeed supports interface inheritance (described here), and like you mention it does not directly support implementation inheritance.
I'd look into this inventive way to get implementation inheritance working, but I think won't since I don't plan to use VB6 ever again.
|
|
|
|
|
I didn't need it often - maybe a couple of times in a year. What I did was use an internal class with the same interface. A
|
|
|
|
|
|
That was the first letter of my first name -_-'
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
... 
