|
Good memories?
Cheers,
विक्रम
"We have already been through this, I am not going to repeat myself." - fat_boy, in a global warming thread
|
|
|
|
|
5 was closer to 6
Real programmers use butterflies
|
|
|
|
|
So maybe the reason 7 8 9 is that they were not as close as 5 and 6.
|
|
|
|
|
In another universe they never developed .NET They have versions of 7, 8, 9 ... That universe is often know as DLL Hell.
So many years of programming I have forgotten more languages than I know.
|
|
|
|
|
Closer than what?
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
VB5 is closer to VB6 than it is to VB4. VB4 didn't do native compilation, IIRC and it still had a 16 bit support portion, again if i remember correctly.
Real programmers use butterflies
|
|
|
|
|
I was being a smart-ass. I actually don't care about VB...
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Who does? TBH it's just useless trivia I know from the bad old days.
Real programmers use butterflies
|
|
|
|
|
Deffo closer to 6 ... I still have a copy of Connell's "Visual Basic 5 from the Ground Up" and the VB6 Manuals. Just to remind me of my roots
|
|
|
|
|
If I'm not mistaken (it's a long time ago), there was one BIG change in 5 that stood out from all the rest: The GUI. Before 5, the GUI had consisted of a lot of loose windows spread over the desktop, and you could see the desktop and other open programs in the background (same was true for Delphi in the first versions).
From 5 and onward, the GUI changed, and you had ONE main MDI parent form open in which you had the other forms and panels, just like now in VS.NET.
I loved that, because that made it much cleaner and more easy to navigate around in.
Anything that is unrelated to elephants is irrelephant Anonymous
- The problem with quotes on the internet is that you can never tell if they're genuine Winston Churchill, 1944
- Never argue with a fool. Onlookers may not be able to tell the difference. Mark Twain
|
|
|
|
|
michaelbarb wrote: Where did VB5 stand in this evolution. Was it closer to 4 or 6? IMO, VB5 was closer to VB6.
VB4 added classes, and added 32-bit support in addition to VB3's 16-bit.
VB5 was 32-bit only, added the ability to create controls, and compiled to native binary. It was part of Visual Studio 97, Microsoft's first attempt (AFAIK) at an integrated development environment.
VB6 added the ability to create web applications. It was part of Visual Studio 6 -- Microsoft standardized on v6 for all included products, as I recall VB6 had the highest version.
I don't recall that the core language changed much between versions. Unlike recent versions of C#, the big difference between versions was major additions to capabilities.
VB4 applications would compile in VB5, and IIRC, in VB6. Compiling down worked unless the program used features not available in the earlier version of VB.
How does one "convert" a VB program to C#? Circa 2003 I tried migrating VB6 programs to VB.NET, and that was a dismal failure -- it was much faster to completely rewrite the program in VB.NET than to try fixing the migrated version.
I'm picky on wording as it affects my response. If you're re-writing the programs, as long as you can read the intent of the VB code, I don't believe it will make much differences in what version the original program was written in.
Note: just for the heckuvit I searched on VB to C# converters -- I found several products that claim to do it. My first thought was "why?", as VB6 has been unsupported for 12 years and effectively dead for 15+ years. However, in the "top 20 languages" surveys I've read over the last few years, VB typically ranks 12 to 15. There's a LOT of VB programs out there, and management isn't going to pay to convert a program unless it's broken ....
|
|
|
|
|
The manual had a lot of screen shots. It was not that difficult to read the code for the control and duplicate it in a WPF. I feel that doing it in a Window Forms would have been harder. I developed a new appreciation for XAML.
The code behind was the usual problem of converting basic to C#. The biggest problem was the program was flat. Without the Object Oriented guides there were a lot of references between windows. All parameters are basically global. Kind of like spaghetti(luckily there are no goto statements any where). I tried some binding in the beginning but with so many I gave up.
I figured out how to do a flat WPF. Having all window open and using Show/Hide. I set up a static class call "g" for global an put a lot of parameters in it. That exercise in itself was interesting and I was thinking of writing it up. Not recommended, just interesting.
Thinking of binding, I realized it is kind of like the new spaghetti.
Someone ask why convert. In the medical industry validation is just part of cost and will be added in eventually. The machine did a destructive test so it only had to do a few each month. Even being run very little eventually the Windows 95 computer is starting to die. The goal is to get the new program to look and run as closely to the old one as possible. This will minimize the cost of paper work to validate the replacement. I call this job security.
So many years of programming I have forgotten more languages than I know.
|
|
|
|
|
I've worked on validated applications so I understand your plight.
Instead of a global class, I've created MDI applications and used the MDI parent as the container for all global information. However, that approach messes up your validation ...
One approach that might help is to create your global object as a class field in the first form. As other forms are created, pass the object by reference to the new forms. IIRC, that should provide what is essentially a global object without actually making it global. You're probably far enough into it that you don't want to backtrack -- just a thought.
|
|
|
|
|
|
raddevus wrote: And in my case and in my experience the gender is incorrect in the comic, because this problem is attributed to men far more often. Interesting. I would agree with Adams in that it is more of a stereotype of women.
|
|
|
|
|
I suppose it is equal to both sides. My point here is that I know a couple of guys who are completely unable to finish a story. After the point of the story is gone, they just linger in your cubicle for days after. You turn around hours later and they're still standing there mumbling about something.
|
|
|
|
|
Ya, that is very annoying.
|
|
|
|
|
I can't say anything to that. I take all audio drivers offline and enter self test mode as soon as women start babbling, screeching, nagging or complaining. I only listen when they try to get insulting. It amuses me.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
Quote: is attributed to men far more often is it? Is it really? Or does that just reflect on the demographics of your particular workplace?
I think the real point is that we all have colleagues that do this. Gender in this case, and in so, so, SO many others, is completely irrelevant.
I think I got your message about why the woman in the comic but way to go killing any humour in that post
|
|
|
|
|
CHill60 wrote: I think I got your message about why the woman in the comic but way to go killing any humour in that post
Well, it was a challenge because I'd probably get responses either way. I think it is irrelevant too actually. But the Adams ended up making it a woman and I was thinking well, all through my years of working in cubicles it has been the other way. It doesn't matter though because all evidence is empirical.
|
|
|
|
|
I think we should name a measurement unit after this guy. Perhaps the unit to measure the buggyness of code. "How is the project coming along?" "Not so good, it's still around 0,5 kilokushim."
What a way to go down in history.
A small mistake![^]
Reminds me of that time when we needed a few new tires for trucks and our Kushim (actually a older IBM) decided to calculate a stockpile to keep, just in case. It was delivered in four or five fully loaded trucks.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
How about a synopsis of the video?
|
|
|
|
|
Ok. Some guy named Kushim from Uruk made an error in his calculations for his stocks more than 5000 years ago. Beer production was a big thing in early civilisation, it seems. It obviously led to stuff like math and writing. The tablets with his bookkeeping (and his errors) have been found, making him the first known person to miscalculate something.
I have lived with several Zen masters - all of them were cats.
His last invention was an evil Lasagna. It didn't kill anyone, and it actually tasted pretty good.
|
|
|
|
|
|
A late aunt of mine was an office worker in the very early days of photocopiers. They were expensive, few and far between, so carbon copy was still common. Her office ran out of carbon paper. They had to resupply, but expecting photocopiers to take over, they made a very small order for 500 sheets. They thought.
When later checking the order form, they had to admit that it clearly indicated a unit size of boxes, each 100 sheets. So, they stocked up 50,000 sheets of carbon paper to last until photocopiers took over.
I believe that they were allowed to return a significant fraction of the lot, but far from all of it. I suspect that if you visit that office today, they may still have a few unopened boxes of carbon paper in their office supplies room.
|
|
|
|