June 3, 2002 at 11:05 am
quote:
Brian, Im curious why you would port to C# from VB. When you say port do you mean rewrite?:-) Since all .net languages are supposed to be "first class", its primarily a matter of differences in the IDE for each language.Andy
http://www.sqlservercentral.com/columnists/awarren/
from VB6 to C#. not VB.NET to C#.
Brian Lockwood
President
LockwoodTech Software
Brian Lockwood
President
ApexSQL - SQL Developer Essentials
June 3, 2002 at 11:18 am
quote:
BrianCould you tell me if you have written a class wrapper that provides a means of accessing the functionality of Excel without accessing low-level formatting calls?
The severe limitation to Excel is this archaic limit on the number of rows per sheet.
Any hints or suggestions greatly appreciated.
Simon
UK
quote:
I like Excel as a report target - you can instantiate it as a COM object and give user's data in a format they are used to.
try adminlog freeware and click "print" button. this will kick your select results to excel to demonstrate the functionality.
regarding rows - the limit is 65,536 rows. If you are bumping up against this limit for reporting maybe you should have more stringent filters. this is a lot of data to sling over the network and write to Excel.
but back to the main point - any client that speaks COM can use Excel as a report target. It is especially good tool to use in finance industry where most users are well versed in Excel.
of course if asp is your bag - check out aspreport freeware [forgive the plug]. my preferred medium is asp and is what i use to build biz apps now.
regarding Cold Fusion - can this product be compared favorably to ASP.NET?
Brian Lockwood
President
LockwoodTech Software
Brian Lockwood
President
ApexSQL - SQL Developer Essentials
June 3, 2002 at 11:32 am
Im still curious, even with VB to C#, why you chose c#? Doesn't matter to me, merely curious about the factors that influenced you.
Andy
June 3, 2002 at 11:36 am
Well I for one would never write a business app using ASP - you just don't have the control of the screen you need, let alone state management.
But anyway, 65536 is no use when doing an overnight report of previous days transactions - it really is silly in this modern age to have any meaningful limit.
I'll look at your suggestions.
Thanks
Simon
June 3, 2002 at 11:52 am
quote:
Well I for one would never write a business app using ASP - you just don't have the control of the screen you need, let alone state management.But anyway, 65536 is no use when doing an overnight report of previous days transactions - it really is silly in this modern age to have any meaningful limit.
I'll look at your suggestions.
Thanks
Simon
i wrote biz apps in VB for years then moved to ASP - actually for expert developers it is a better medium because you have MORE control over screen not less.
look at this screen shot of a rich client using asp web interface
http://www.lockwoodtech.com/articles/ice_graphic.htm
with html you can use frames - there is no equivalent in windows development. with html you can dynamically create new controls like buttons, radio buttons, check boxes etc to make a totally dynamic interface - with VB you must use control arrays which are really not a good way to go for a real dynamic interface.
you can use event driven programming with client side vbscript (not javascript) that will respond to control clicks, changes, selections just like in a client server app.
and finally deployment is a breeze. this app was rolled out to 40 call center reps, managers, associates, externall users outside the company etc. running on an inttranet there is NO deployment. originally it was a VB app. and installs were a nightmare
Brian Lockwood
President
LockwoodTech Software
Brian Lockwood
President
ApexSQL - SQL Developer Essentials
June 3, 2002 at 12:04 pm
I'll skip the ASP vs VB discussion, but I'd like to hear why the installs were a problem with VB? I find that using MSI for deployment I have almost no issues.
Andy
June 3, 2002 at 12:06 pm
quote:
Im still curious, even with VB to C#, why you chose c#? Doesn't matter to me, merely curious about the factors that influenced you.Andy
http://www.sqlservercentral.com/columnists/awarren/
if you are asking why C# vs VB.NET this is a thread in it's own right and will get hearty posts by advocates by both.
If it were up to me alone I would use VB.NET. I love the Visual Basic language and have programmed variants of it from VBA to Visual Basic to VBScript/ASP for my entire career.
but there are other variables - commercial, employee related (what they want to do), career related, the perception that VB.NET is not enterprise level and C# is and so forth.
so I am not a strong advocate in this argument but I am sure others will be.
Brian Lockwood
President
LockwoodTech Software
Brian Lockwood
President
ApexSQL - SQL Developer Essentials
June 3, 2002 at 12:15 pm
quote:
I'll skip the ASP vs VB discussion, but I'd like to hear why the installs were a problem with VB? I find that using MSI for deployment I have almost no issues.Andy
http://www.sqlservercentral.com/columnists/awarren/
well for starters we had Mac clients which couldn't use the app at all.
also external consultants who would have to be emailed large install files could now just dial in to intranet.
for win clients each time a new control, component was added new install had to be created, downloaded, installed.
users did not have same versions of the app.
some controls just didn't work on some machines we had Win98, WinME mostly. we did not know why.
with web apps. there is no install. you can even do a hot replace of an asp file without taking system off line.
with .net though - dll, ocx hell is supposed to be over. the installs are "soft" and may result in a resurgence of fat client apps. it'll be too late for me though.
what is your deployment process
Brian Lockwood
President
LockwoodTech Software
Brian Lockwood
President
ApexSQL - SQL Developer Essentials
June 3, 2002 at 12:40 pm
We use asp for a lot of minor apps, and for stuff that has to be externally accessible by clients. Internally for large apps we have a process in place where we can auto deploy just the exe (older stuff mainly) where we are not using COM dll's of our own. For newer projects we're deploying via MSI and organiational policies, and I have a work in progress that simulates the concept of 'windows update' to deploy new builds. Nice part about msi is it handles all the dll registration stuff. Everything internally runs Win2K Pro, so its a very stable very fast environment even across our T1 wan.
Andy
June 3, 2002 at 12:57 pm
quote:
We use asp for a lot of minor apps, and for stuff that has to be externally accessible by clients. Internally for large apps we have a process in place where we can auto deploy just the exe (older stuff mainly) where we are not using COM dll's of our own. For newer projects we're deploying via MSI and organiational policies, and I have a work in progress that simulates the concept of 'windows update' to deploy new builds. Nice part about msi is it handles all the dll registration stuff. Everything internally runs Win2K Pro, so its a very stable very fast environment even across our T1 wan.Andy
http://www.sqlservercentral.com/columnists/awarren/
we run inno setup at lockwoodtech. it is freeware and i highly reccommend it. it does not leverage msi though so would not be best for your shop.
another trick i used at client site for binary installations accross large user base was i gave users a .bat file which ftp'd down the .exe from web central server and replaced older version. users would just click on shortcut to bat file to "install" new .exe.
Brian Lockwood
President
LockwoodTech Software
Brian Lockwood
President
ApexSQL - SQL Developer Essentials
June 3, 2002 at 5:48 pm
quote:
but there are other variables - commercial, employee related (what they want to do), career related, the perception that VB.NET is not enterprise level and C# is and so forth.
I would have to disagree there since they have removed almost all the limitation VB had and added classing in the .NET framework. Also all code is compiled down to machine level code so a VB.NET app can be written so that it works and compiles exactly the same as a C# app. However, I would say if you are going down the C# road consider C++ instead this way you can build more machine idenpendent code now and compile C++ as they currently are now.WIth what was done to VB with .NET and the way C++ works C# seems almost needless at all.
"Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)
June 3, 2002 at 5:55 pm
I tend to agree with Antares. Having VB.NET support inheritence, real classes, etc. there is not a substantial difference from c#. Personally I prefer C#, but that's personal. No real logic for choosing it over VB.
As far as the reasons given for issues, this is the main reason the web has taken off. It removes many of the install/platform issues. I'd use ASP. You can easily control most things you need, though I'd avoid frames. Good app design will matter much more than the language.
Steve Jones
June 3, 2002 at 7:24 pm
quote:
I tend to agree with Antares. Having VB.NET support inheritence, real classes, etc. there is not a substantial difference from c#. Personally I prefer C#, but that's personal. No real logic for choosing it over VB.As far as the reasons given for issues, this is the main reason the web has taken off. It removes many of the install/platform issues. I'd use ASP. You can easily control most things you need, though I'd avoid frames. Good app design will matter much more than the language.
Steve Jones
well you are both talking about the merits - i indicated "the perception ..." one can't really ague that the general perception exists is that VB.NET is on parity with C#. the facts may support it but doesn't alter the perception.
As I indicated I myself am ambivalent about the two (C# vs. VB.NET) but most people are not. Decision makers see the "C" in C# and think enterprise. They see the "B" for Basic in VB and think hack. Also - MSFT didn't help this when they "dumbed down" VB.NET in response to protests from some of the squeekiest wheels in the VB community about backward compatability.
But in general - any .NET language leverages the full power of the CLR, ADO.NET and can be implemented in ASP.NET - the rest is really just grist for discussion forums and personal preference.
for some interesting VB.NET vs C# threads check out http://www.angrycoder.com. these guys seem to lean C# mostly because they are pissed off about VB.NET changes (see above).
Brian Lockwood
President
LockwoodTech Software
Brian Lockwood
President
ApexSQL - SQL Developer Essentials
June 3, 2002 at 7:36 pm
quote:
quote:
but there are other variables - commercial, employee related (what they want to do), career related, the perception that VB.NET is not enterprise level and C# is and so forth.I would have to disagree there since they have removed almost all the limitation VB had and added classing in the .NET framework. Also all code is compiled down to machine level code so a VB.NET app can be written so that it works and compiles exactly the same as a C# app. However, I would say if you are going down the C# road consider C++ instead this way you can build more machine idenpendent code now and compile C++ as they currently are now.WIth what was done to VB with .NET and the way C++ works C# seems almost needless at all.
"Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)
one thing to note. you can run managed C++ in C# - so you can take full advantage of VS.NET and rad capabilities of C# but still run blocks of C++ code.
In terms of how this code is burned into the .exe and whether it bypasses the .NET compiler's intermediate language straight to machine code, as C++ does, I don't know. But seems like it may be a compelling advantage for C++ programmers who would like to take advantage of winforms, webforms in .NET
Brian Lockwood
President
LockwoodTech Software
Brian Lockwood
President
ApexSQL - SQL Developer Essentials
June 3, 2002 at 8:00 pm
I didn't say it didn't offer anything but consider the fact you can create full C++ classes and utilize them in VB.net so that cross bread is more natural as the C++ and VB knowledgeable developer can easily build the same thing quickly. Also it makes it easier for C++ and VB developers to work directly in the same application together for the same goal. C# was design to get VB programmers closer to C but when you consider what they did with VB.NET it was already shoved that way anyway. Had they left VB alone then C# would have been a better concept.
"Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)
Viewing 15 posts - 31 through 45 (of 64 total)
You must be logged in to reply to this topic. Login to reply