BorlandTalk.com Borland discussion newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  .NET - end user reality check Goto page 1, 2, 3, 4, 5  Next          BorlandTalk.com Forum Index -> Delphi Non-Technical View previous topic :: View next topic   Author Message Peter Sleuth Guest Posted: Tue Jun 28, 2005 4:50 pm    Post subject: .NET - end user reality check Hi, in the meantime I have some .NET-end user apps on my machines, and I would just like to share my experience on some real live end user apps. I have several machines available for testing, my main development machine (notebook running Win32), another development machine (desktop) running Win64, a media center pc at home etc. My experience so far is: a) .NET Starteam client embedded in Delphi 2005. Initially after installing Delphi2005 the .NET Starteam client worked like a breeze. It was visually far more appealing than its Java based counterpart, the stand alone Starteam client. But after a couple of weeks, it stopped to work, giving me instead an error message called "Network Problem"-"Cannot contact server". After browsing the newsgroups where I couldn´t find any answer (but someone else having the same problem), I gave up on this. Needless to say, that the Java based Standalone Starteam client still works without any problems with the same server. Sigh. b) Blogreader IntraVNews (Outlook embedded) While the .NET based IntraVNews works as expected (and is very nice, by the way), whenever I exit Outlook its process won´t finish and still remains hung in memory (as seen in task manager), sometimes accompanied by some obscure .NET error message. Sigh. c) I recently bought a new external USB-TV-Box for my notebook. Its configuration app is .NET-based, and guess what: It doesn´t work on my laptop. It results in an error message that the performance counter service isn´t running and therefore it can´t start "System.InvalidOperationException: Process performance counter is disabled, so the requested operation cannot be performed". Reactivating the performance counter didn´t help either. After googling for this, I found a message from someone at Microsoft who acknowledged that some basic functionality in .NET used to get process information is unfortunately somehow bound to the performance counter service and therefore often fails, something Microsoft intends to change in .NET 2.0. Guess what, without running the configuration app first, you can´t work with the TV-Box. Trying the TV-box on a different machine, the .NET based settings app works fine, but on the machine where I want to actually use it it just doesn´t work, making the TV-Box actually worthless for me. Sigh. d) Installing the latest ATI-drivers (catalyst) on a Win64 machine results in a surprise, the .NET based "CATALYST Control Center" isn´t included. So anyone who thinks that .NET is the way to 64-bit, please note that ATI currently obviously sees things completely different. Sigh. e) Today I tried to install the ContactManagement/CRM-software Act7 on my machine, which is a .NET application. After starting the setup-program, I get the error message (translated from german): "installation can´t be continued until file and printer sharing is activated". Needless to say that all my network connections already have file and printer sharing activated. So I can´t even install that app. Will have to try it on a different machine. Sigh. So just let me sum this up. Out of five .NET apps, I have got: - one (.NET D2005 embedded Starteam client) that initially worked fine but then stopped and never worked again - one that works fine (IntraVNews) but results in a hanging process on exiting the main app and weird error messages - one app that refuses to work on one machine but works on another machine (settings app for a TV-tuner USB-Box) - one graphics card driver on Win64 that doesn´t include its .NET based control center (known from the Win32-driver) - on app that even refuses to install (Act7). All these real live experiences are done on three different machines so far, so this can´t be a problem specific to the enviroment of one single machine. My personal opinion: I am really fed up right now. Whenever in the future I want to buy a new software or hardware (that requires software to work), I will from now on make sure that it doesn´t require the .NET framework, I will avoid .NET apps like the plague whenever possible. I wouldn´t necessarily say that .NET itself is faulted, but it seems that ..NET apps (while theoretically very easy to deploy (just say "xcopy-deployment")), are very sensitive to the enviroment and therefore sometimes just refuse to work as intended. Either the authors of .NET apps don´t do enough testing to ensure that their apps work everywhere as expected, or .NET makes this far more complicated than expected. Please note that all five applications are commercial apps, we aren´t talking free goodies or something similar here. Anyone else having similar experiences? Best regards, -Peter Back to top Craig Stuntz [TeamB] Guest Posted: Tue Jun 28, 2005 5:08 pm    Post subject: Re: .NET - end user reality check Peter Sleuth wrote: Quote: a) .NET Starteam client embedded in Delphi 2005. Initially after installing Delphi2005 the .NET Starteam client worked like a breeze. It was visually far more appealing than its Java based counterpart, the stand alone Starteam client. But after a couple of weeks, it stopped to work, giving me instead an error message called "Network Problem"-"Cannot contact server". I don't actually think this is a .NET issue, but that's beside the point, as I'd like to help you get this working. I'm pretty sure that D2005 SP 2 introduced a problem a lot like this. This was fixed in an update to SP 2 and should be fixed in SP 3 as well. Look at the bds.exe.config update available from the registered users site. As an aside, the normal standalone StarTeam client is a Win32 app, not a Java app. There is a Java cross-platform client, but I can't see why anyone on Windows would use it. -- Craig Stuntz [TeamB] . Vertex Systems Corp. . Columbus, OH Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz IB 6 versions prior to 6.0.1.6 are pre-release and may corrupt your DBs! Open Edition users, get 6.0.1.6 from http://mers.com Back to top Peter Sleuth Guest Posted: Tue Jun 28, 2005 5:34 pm    Post subject: Re: .NET - end user reality check "Craig Stuntz wrote Quote: Peter Sleuth wrote: a) .NET Starteam client embedded in Delphi 2005. Initially after installing Delphi2005 the .NET Starteam client worked like a breeze. It was visually far more appealing than its Java based counterpart, the stand alone Starteam client. But after a couple of weeks, it stopped to work, giving me instead an error message called "Network Problem"-"Cannot contact server". I don't actually think this is a .NET issue, but that's beside the point, as I'd like to help you get this working. I'm pretty sure that D2005 SP 2 introduced a problem a lot like this. This was fixed in an update to SP 2 and should be fixed in SP 3 as well. Look at the bds.exe.config update available from the registered users site. Thanks for your support. Unfortunately I have already D2005 SP3 installed (including the bds.exe.config), and the problem still remains. This seems to underscore my point that: "I wouldn´t necessarily say that .NET itself is faulted, but it seems that ..NET apps (while theoretically very easy to deploy (just say "xcopy-deployment")), are very sensitive to the enviroment and therefore sometimes just refuse to work as intended. Either the authors of .NET apps don´t do enough testing to ensure that their apps work everywhere as expected, or .NET makes this far more complicated than expected." I remember that when I freshly installed D2005 and the embedded .NET Starteam client was running, it did only work when I was in the office but didn´t work when remotely logging into the Network using a VPN-connection (needless to say that working over a VPN-connection just worked fine using the standalone client). I assumed that this probably was due to some security settings in the .NET runtime, but wasn´t able to dissolve that issue. Quote: As an aside, the normal standalone StarTeam client is a Win32 app, not a Java app. There is a Java cross-platform client, but I can't see why anyone on Windows would use it. Given its look and feel, I would have assumed that the standalone StarTeam client is a Java app, but you are correct, the app that I am using is the Win32-client ;-) Best regards, -Peter Back to top Craig Stuntz [TeamB] Guest Posted: Tue Jun 28, 2005 6:14 pm    Post subject: Re: .NET - end user reality check Peter Sleuth wrote: Quote: Thanks for your support. Unfortunately I have already D2005 SP3 installed (including the bds.exe.config), and the problem still remains. Is the message you posted the *precise* message you are getting from Delphi? If not, could you tell me what it is? Thanks, -Craig -- Craig Stuntz [TeamB] . Vertex Systems Corp. . Columbus, OH Delphi/InterBase Weblog : http://blogs.teamb.com/craigstuntz IB 6 versions prior to 6.0.1.6 are pre-release and may corrupt your DBs! Open Edition users, get 6.0.1.6 from http://mers.com Back to top Mark G. Zeringue Guest Posted: Tue Jun 28, 2005 6:14 pm    Post subject: Re: .NET - end user reality check "Peter Sleuth" <psleuth (AT) nospam (DOT) gmail.com> wrote Quote: a) .NET Starteam client embedded in Delphi 2005. Initially after installing Delphi2005 the .NET Starteam client worked like a breeze. It was visually far more appealing than its Java based counterpart, the stand alone Starteam client. But after a couple of weeks, it stopped to work, giving me instead an error message called "Network Problem"-"Cannot contact server". After browsing the newsgroups where I couldn´t find any answer (but someone else having the same problem), I gave up on this. Needless to say, that the Java based Standalone Starteam client still works without any problems with the same server. Sigh. We had this issue on both of our machines from day one. I called Borland support on this one and it required a Microsoft Hotfix to correct. From my post on this on 4/29/2005 in the StarTeam news group: As it turns out this is referenced in a MS Article#819777, requires a J# HotPatch to resolve. Hope this fixes things for you. mark Back to top Kostya Guest Posted: Tue Jun 28, 2005 7:55 pm    Post subject: Re: .NET - end user reality check I do a lot of research in few areas. Often I hunt for the programs related to those areas and download them to see how they work. Lately more and more of the apps/utilities I download implemented in ..NET. Guess what. Most of those crash on the first run with some weird messages. The rest work ok. Now I could've investigated all those messages and try to find reasons/fixes. However I feel that it'll take away too much of my time and it is not my job as a customer to figure all those .NET related problems. Of course I do have latest updates from MS. Well. Couple of apps that did work gave a complete impression as they were native (if you do not look at process view of course). Nice looking and responsive. Those however were little utilities and I would not expect anything else. So after having such experience whenever I see implemented in .NET I just skip the whole thing completely. Let them sort their own ... first and then try it on customers. All I know that 90% C++ apps that I download work flawlessly. Kostya Back to top marc hoffman Guest Posted: Tue Jun 28, 2005 10:07 pm    Post subject: Re: .NET - end user reality check Kostya, Quote: Most of those crash on the first run with some weird messages. The rest work ok. Now I could've investigated all those messages and try to find reasons/fixes. However I feel that it'll take away too much of my time and it is not my job as a customer to figure all those .NET related problems. of course, if you download a Win32 application and it it's just crappy as hell (and i've seen my fair share of them), i would assume you'll first look for blame in the instable Win32 api as well, before stopping to thing that maybe it's just a badly written app? Back to top Andrea Raimondi Guest Posted: Tue Jun 28, 2005 10:34 pm    Post subject: Re: .NET - end user reality check Peter Sleuth wrote: Quote: Anyone else having similar experiences? I try to avoid dotNET apps, anyway I'm using Paint.NET which looks nice and didn't do strange things as of now. Anyway, I'm willing to contribute my porting experience of a fairly trivial app to VCL.NET . The app I'm talking about is Client Dataset Creator, available on CodeCentral. I was getting a strange error at startup(I don't remember it exactly), anyway now it doesn't compile anymore because it complains about a "duplicate resource" TMAINFRM. This is my project source: program CDSCreator; {%DelphiDotNetAssemblyCompiler '$(SystemRoot)microsoft.netframeworkv1.1.4322System.Drawing.dll'} uses Forms, CDC4NET.MainCode in 'CDC4NET.MainCode.pas' {MainFrm}, CDSSaveAsFileCode in 'CDSSaveAsFileCode.pas' {CDSSaveAsFileFrm}, CDC4NET.uFieldConvert in 'CDC4NET.uFieldConvert.pas', CDC4NET.FieldEngine in 'CDC4NET.FieldEngine.pas'; {$R *.res} [STAThread] begin Application.Initialize; Application.CreateForm(TMainFrm, MainFrm); Application.Run; end. Needless to say, I *do* have a MainCode.pas(without namespace prefix) among the files in the directory, but I suppose that Delphi should be able to correctly identify the right one... misteries... Quote: Best regards, Cheers, Quote: -Peter Andrew Back to top Bryce K. Nielsen Guest Posted: Tue Jun 28, 2005 11:19 pm    Post subject: Re: .NET - end user reality check Quote: of course, if you download a Win32 application and it it's just crappy as hell (and i've seen my fair share of them), i would assume you'll first look for blame in the instable Win32 api as well, before stopping to thing that maybe it's just a badly written app? If the majority of the Win32 apps he installed were "crappy as hell", then he probably would assume it was the unstability of Windows. But that is not the case... -BKN Back to top Kostya Guest Posted: Tue Jun 28, 2005 11:21 pm    Post subject: Re: .NET - end user reality check Quote: of course, if you download a Win32 application and it it's just crappy as hell (and i've seen my fair share of them), i would assume you'll first look for blame in the instable Win32 api as well, before stopping to thing that maybe it's just a badly written app? That could as well be the case. And yes there are lots of crappy C++ apps. However not in the areas I was looking at. One could come to a couple of conclusions: One would be that before one could write something in C++ that person has to understand lots of details and that thing alone could provoke higher level of expertise. .NET is much easier for writing simple apps and could attract persons that otherwise would not do much programming so to speak. I remember seeing resumes of persons claiming to be programmers (HTML language) in the hey days of .COM and demanding $80hr. The other could be that the technology is not mature enough and there are lots of pending issues to be resolved. Win32 and Windows in general had taken years and years to become what it is now. It'll probably take quite a while to bring .NET to the same state. While the dust settles down many customers and/or programmers might as well not to be a guinea pigs and wait till the whole thing settles one or the other way. The other problem with .NET in this case is that while DOS16/Win16/Win32 and DOS/Win3.1/WinNT type of successions provided immediate and visible benefits to many programmers and customers .NET IMO does not have such appeal to as wide audience as the previous technologies. Kostya Back to top Alvaro GP Guest Posted: Wed Jun 29, 2005 12:53 am    Post subject: Re: .NET - end user reality check Kostya wrote: Quote: Win32 and Windows in general had taken years and years to become what it is now. It'll probably take quite a while to bring .NET to the same state. And in the meantime Win64 is here, and it looks unforgiving.. Win64 vs. .NET Who will rule? Back to top Kostya Guest Posted: Wed Jun 29, 2005 1:02 am    Post subject: Re: .NET - end user reality check Quote: Who will rule? Dunno. IMO in a future it'll be a combination. Something like what managed C++ does now and C++/CLI will do later. When/If I decide to move my lazy butt for major upgrade (read rewrite) of my product I'll most likely do it using managed C++ unless other vendors could offer the technology equivalent of the latter assuming it makes sense ROI-wise Kostya Back to top Mauro Venturini Guest Posted: Wed Jun 29, 2005 8:54 am    Post subject: Re: .NET - end user reality check I used a lot of small/medium .NET utilities (starting of course from Reflector) and their working and quality seemed very good to me, but they are utilities. A larger application I used much is Simego SQL Tool Explorer (a replacement for SQL Server Enterprise Manager). It is quite a large application (1.7 MByte managed executable plus a bunch of private assemblies) and it worked flawlessly and I'm very satisfied with it. It is true that advertising a new programming environment/technology as so easy to use to be almost a "no brainer" (and it certainly is compared to other technologies as MFC, ATL, COM) may induce some almost "no brained" people to think that even programming is a "no brainer" endeavour. But, as Edsger Dijkstra often remarked, it is not. Back to top Lurkio Guest Posted: Wed Jun 29, 2005 10:03 am    Post subject: Re: .NET - end user reality check Peter Sleuth wrote: Quote: in the meantime I have some .NET-end user apps on my machines <snip /loads/ of problems with various applications> Quote: So just let me sum this up. Out of five .NET apps, I have got: - one (.NET D2005 embedded Starteam client) that initially worked fine but then stopped and never worked again - one that works fine (IntraVNews) but results in a hanging process on exiting the main app and weird error messages - one app that refuses to work on one machine but works on another machine (settings app for a TV-tuner USB-Box) - one graphics card driver on Win64 that doesn´t include its .NET based control center (known from the Win32-driver) - one app that even refuses to install (Act7). Sorry to hear about your problems, I've had a few issues myself though not quite as large a list as yours. The most recent one was where a new CRM system (Avidian Prophet) would not install on one of our office machines (failing with no explanatory error message other than '"Prophet failed to install") because of the existence (I eventually found out) of a previous installation of a .Net 1.1 /beta/ that the (non-IT literate) user had no clue about even having. We needed the new CRM system on the machine so uninstalled the other framework version and Prophet subsequently installed fine. We still have no idea about what installed the beta 1.1 and whether the mystery application that did install it is now broken... One common feature of .Net apps seems to me to be the lack of decent error messages that appear when something does go wrong. I'm not sure why this should be the case. Maybe fledgling .Net developers seem to think that the framework will always throw up some half-decent, human readable message on its own whenever there is a problem - well, IME it doesn't :-) Quote: All these real live experiences are done on three different machines so far, so this can´t be a problem specific to the enviroment of one single machine. My personal opinion: I am really fed up right now. Whenever in the future I want to buy a new software or hardware (that requires software to work), I will from now on make sure that it doesn´t require the .NET framework, I will avoid .NET apps like the plague whenever possible. It will become increasingly difficult to do so, I'm afraid...and I have a horrible feeling that the kind of problems you are having are just the tip of the iceberg as .Net use increases, more framework versions appear, and more OS sub-systems are de-coupled as deployables (Avalon). My gut tells me that things will get worse before they get better. Either Microsoft will start addressing these problems or keep on pretending that there /are/ no problems... :-( Quote: I wouldn´t necessarily say that .NET itself is faulted, but it seems that .NET apps (while theoretically very easy to deploy (just say "xcopy-deployment")), are very sensitive to the enviroment and therefore sometimes just refuse to work as intended. Either the authors of .NET apps don´t do enough testing to ensure that their apps work everywhere as expected, or .NET makes this far more complicated than expected. I find some of the claims about how .Net resolves DLL hell and makes deployment easier /very/ ironic. Copying your exe and any required DLLs to the same directory along with a config file is something you could do since Windows development began. With the advent of Windows 95, we were told for years to use the registry instead and that ini files were old hat...now the wheel has turned again and it is recommended we use "Isolated Storage" :-) IMO, the choice of being able to tie an application to a specific framework version instead of letting it "float up" to use the latest version available, allied to the mix of GAC and local assemblies will make a /horrible/ mess of our hard drives with all of those different framework versions and assemblies all over the place. "Assembly Armageddon", as I've said in here before :-) Back to top Mauro Venturini Guest Posted: Wed Jun 29, 2005 10:45 am    Post subject: Re: .NET - end user reality check Quote: One common feature of .Net apps seems to me to be the lack of decent error messages that appear when something does go wrong. I'm not sure why this should be the case. Maybe fledgling .Net developers seem to think that the framework will always throw up some half-decent, human readable message on its own whenever there is a problem - well, IME it doesn't This is certainly a problem during the loading and handover from unmanaged to managed worlds. If a problem happens here (and all the problem related to assemblies missing and security settings do happen here) only a standard message appears without any real explanation of the problem. This may somewhat cured, there was a very interesting blog on Wintellect http://wintellect.com/WEBLOGS/wintellect/archive/2005/03/30/941.aspx Unfortunately, this requires change the project startup code generated by the IDEs (BDS and VS do almost the same) and I thik few people know about that. For example the standard Delphi WinForm .dpr ends like this begin Application.Run(<main form class>.Create); end. while it should be sothing like that begin try TExceptionHandler.Create; Application.Run(<main form class>.Create); except on E: Exception do begin if TExceptionHandler.Ready then raise else TExceptionHandler.Handle(E); end else begin if TExceptionHandler.Ready then raise else TExceptionHandler.Handle(nil); end; end; end. where TExceptionHandler is something like this type TExceptionHandler = class(System.Object) strict private class var Instance: TExceptionHandler; FReady: Boolean; FSimpleMessageBox: Boolean; FExitOnError: Boolean; FOnError: UnhandledExceptionEventHandler; strict private procedure ThreadExceptionHandler(sender: System.Object; e: ThreadExceptionEventArgs); procedure UnhandledExceptionHandler(sender: System.Object; e: UnhandledExceptionEventArgs); public constructor VirtualCreate; virtual; public class property Ready: Boolean read FReady; class property SimpleMessageBox: Boolean read FSimpleMessageBox write FSimpleMessageBox; class property ExitOnError: Boolean read FExitOnError write FExitOnError; class procedure Handle(E: Exception); class property OnError: UnhandledExceptionEventHandler add FOnError remove FOnError; class function Create: TExceptionHandler; reintroduce; end; constructor TExceptionHandler.VirtualCreate; begin inherited Create; Include(AppDomain.CurrentDomain.UnhandledException, UnhandledExceptionHandler); FReady := true; Include(Application.ThreadException, ThreadExceptionHandler); end; class function TExceptionHandler.Create: TExceptionHandler; begin if not Assigned(Instance) then Instance := VirtualCreate; Result := Instance; end; class procedure TExceptionHandler.Handle(E: Exception); var ProductName: string; begin try try ProductName := Application.ProductName; except ProductName := 'Application.ProductName unavailable'; end; if not Assigned(E) then begin if FSimpleMessageBox or not Assigned(FOnError) then MessageBox.Show('Exception information unavailable',ProductName) else FOnError(nil,UnhandledExceptionEventArgs.Create(nil,true)); end else if FSimpleMessageBox then MessageBox.Show(E.ToString,ProductName) else begin // if they have a handler then we use it otherwise we show a more complete error box. if not Assigned(FOnError) then begin with TDefaultErrorDialog.Create(E,ProductName) do begin ContinueBtn.Enabled := false; ShowDialog; Free; end; end else FOnError(nil,UnhandledExceptionEventArgs.Create(E,true)); end; except // last resort: try to leave a trace if not Assigned(E) then Trace.Write(E.ToString + Environment.NewLine + 'Product Name: ' + ProductName) else Trace.Write('Product Name: ' + ProductName + Environment.NewLine + 'Exception information unavailable'); end; end; procedure TExceptionHandler.ThreadExceptionHandler(sender: TObject; e: ThreadExceptionEventArgs); var ProductName: string; begin try try ProductName := Application.ProductName; except ProductName := 'Application.ProductName unavailable'; end; if FSimpleMessageBox then MessageBox.Show(e.Exception.ToString,ProductName) else begin // if they have a handler then we use it otherwise we show a more complete error box. if not Assigned(FOnError) then begin with TDefaultErrorDialog.Create(e.Exception,ProductName) do begin ContinueBtn.Enabled := not FExitOnError; ShowDialog; Free; end; // skip out early, the dialog would have closed the app if it were requested. Exit; end else FOnError(sender,UnhandledExceptionEventArgs.Create(e.Excepti on,FExitOnError)); end; except // last resort: try to leave a trace Trace.Write('Product Name: ' + ProductName + Environment.NewLine + e.Exception.ToString); end; if FExitOnError then Application.Exit; end; procedure TExceptionHandler.UnhandledExceptionHandler(sender: System.Object; e: UnhandledExceptionEventArgs ); var ProductName: string; begin try try ProductName := Application.ProductName; except ProductName := 'Application.ProductName unavailable'; end; if FSimpleMessageBox then MessageBox.Show((e.ExceptionObject as Exception).ToString,ProductName) else begin // if they have a handler then we use it otherwise we show a more complete error box. if not Assigned(FOnError) then begin with TDefaultErrorDialog.Create(e.ExceptionObject as Exception,ProductName) do begin ContinueBtn.Enabled := not e.IsTerminating and not FExitOnError; ShowDialog; Free; end; // skip out early, the dialog would have closed the app if it were requested. Exit; end else FOnError(sender,UnhandledExceptionEventArgs.Create(e.Excepti onObject,e.IsTerminating or FExitOnError)); end; except // last resort: try to leave a trace Trace.Write('Product Name: ' + ProductName + Environment.NewLine + (e.ExceptionObject as Exception).ToString); end; if FExitOnError then Application.Exit; end; where TDefaultErrorDialog is a dialog that show more meaningful info on error. Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         BorlandTalk.com Forum Index -> Delphi Non-Technical All times are GMT Goto page 1, 2, 3, 4, 5  Next Page 1 of 5   Jump to: Select a forum C++ Builder Newsgroups----------------C++ BuilderC++ Builder (ActiveX)C++ Builder (Announcements)C++ Builder (Command Line Tools)C++ Builder DatabasesC++ Builder Databases (ADO)C++ Builder Databases (Desktop)C++ Builder Databases (InterBase Express)C++ Builder Databases (Multi-Tier)C++ Builder Databases (SQL Servers)C++ Builder (Graphics)C++ Builder (IDE)C++ Builder (Internet)C++ Builder (Internet Socket)C++ Builder (Internet Web)C++ Builder (Jobs)C++ Builder (Language)C++ Builder (Language C++)C++ Builder (Compatibility with MFC)C++ Builder (Native API)C++ Builder (Non-Technical)C++ Builder (Students)C++ Builder (Third Party Tools)C++ Builder (Upgrade)C++ Builder (VCL)C++ Builder (VCL Components Usage)C++ Builder (VCL Components Development)C++ Builder (VCL Usage)C++ Builder (WinAPI)C++ Builder Installation Delphi Newsgroups----------------Delphi (General)Delphi ActiveX Controls UsageDelphi ActiveX Controls DevelopmentDelphi As400Delphi DatabasesDelphi Databases (ADO)Delphi Databases (dbExpress)Delphi Databases (Desktop)Delphi Databases (InterBase Express)Delphi Databases (Multi-Tier)Delphi Databases (SQL Servers)Delphi DeploymentDelphi GraphicsDelphi IDEDelphi InternationalizationDelphi InternetDelphi Internet Isapi-WebBrokerDelphi Internet WebSnapDelphi Internet WinsockDelphi JobsDelphi Language BASMDelphi Language ObjectPascalDelphi Model Driven Architecture (General)Delphi Model Driven Architecture (Third Party)Delphi MultimediaDelphi Native APIDelphi Non-TechnicalDelphi ObjectPascalDelphi OLE AutomationDelphi OO designDelphi OpenToolsAPIDelphi Reporting-ChartingDelphi RTLDelphi StudentsDelphi TeamSourceDelphi Thirdparty ToolsDelphi Thirdparty Tools (General)Delphi Thirdparty Tools (IntraWeb)Delphi Thirdparty Tools (RaveReports)Delphi UpgradeDelphi VCLDelphi VCL ComponentsDelphi VCL Components UsingDelphi VCL Components WritingDelphi WebServices SOAPDelphi WinAPIDelphi XMLDelphi Installationcomp.lang.pascal.delphi.components.misccomp.lang.pascal.delphi.components.usagecomp.lang.pascal.delphi.components.writingcomp.lang.pascal.delphi.databasescomp.lang.pascal.delphi.misccomp.sources.delphi JBuilder Newsgroups----------------JBuilderJBuilder AnnouncementsJBuilder Applet IssuesJBuilder As400JBuilder CompilerJBuilder CORBA/RMIJBuilder DatabasesJBuilder DB SwingJBuilder DebuggerJBuilder DeploymentJBuilder DocumentationJBuilder EnterpriseJBuilder HandheldJBuilder IDEJBuilder JavaJBuilder JavaAPIJBuilder Java LanguageJBuilder Java SwingJBuilder Java BeansJBuilder Java Beans UsageJBuilder Java Beans DevelopmentJBuilder JBCLJBuilder JDataStoreJBuilder JobsJBuilder LinuxJBuilder MacintoshJBuilder & MobileSetJBuilder MultiLingual AppsJBuilder Non-TechnicalJBuilder OpenToolsJBuilder Servlets (JSP)JBuilder StudentsJBuilder Team DevelopmentJBuilder Thirdparty ToolsJBuilder UpgradeJBuilder Installation InterBase Newsgroups----------------InterBaseInterBase Bug DiscussionInterBase GeneralInterBase IBConsoleInterBase OpenSourceInterBase ReplicationInterBase SQLInterBase ThirdpartyInterBase Installation Miscellaneous Borland Newsgroups----------------AppCenterAppServerEnteraVisiBroker  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.