Delphi 'Robustness' - Larger Apps ?

Let me start by saying that I LOVE Delphi, having used it since version 1.0, though must also confess that I'm a part-time programmer who has largely worked on my own ...

I have a project that 'growed', now has well over 100 pages of code, this is in some 16 units.  For the most part this has gone pretty smoothly ...  However, recently I've noticed the occasional spot of unusual behaviour.  For example, last week when running from the IDE the program would stop at a certain line of code as if a break point was set there (it wasn't), doing a full build didn't change it, & it persisted on & off for a few days.   The solution - I simply swapped the 6-8 line block of code with the following block of code (fortunately in this situation it didn't matter the order) and the problem went away.   Another situation I had a problem that worked OK when running the exe but not when running from the IDE.   I think there might have been one or two other instances which I've forgotten the detail of ...

Is there some sort of 'ceiling' above which the compiler becomes less robust ?   Has anyone else experienced this sort of thing (that they couldn't explain) ?    

( BTW, I'm using D6, though I have D7 (&D8) I started this project with D6 & have stuck with this )

Comments appreciated.
Who is Participating?
For your breakpoint problem, this is fairly common.
Go to View -> Debug Windows -> Breakpoints and delete any "orphan" breakpoints.
For the question of "robustness", I don't think, by experience, this has anything to do with the size of your program.
100 pages of code, at 70 lines per page is 7,000 lines. I have Delphi applications with over 50,000 lines, and yes, Delphi somethings crashes, but it does also with much much smaller apps.
Stick to Delphi, you've got the best RAD product around !
Wim ten BrinkSelf-employed developerCommented:
All I know is that the bigger the project, the more bugs it will have... :-)
The Delphi IDE might sometimes remember old breakpoints and unfortunately, in the Windows API the Microsoft developers included a few hard-coded breakpoints. It could be related to anything. I recently had a nasty bug to solve in a small console application. It kept raising a runtime error 207 and I just didn't understand why. But it was a simple bug that resulted in a division by 0 sometimes. :-) It could be that there's a bug in that part of code.
It sometimes also helps to turn off optimization. Optimization can inprove performance quite a bit sometimes but it could also introduce some unexplainable problems.
about the exceptions ... I had this with a project ot 400 000 lines of code. It stopped on about 20 points without breakpoint...  I don't know why. Then a friend of mine told a trick which helped.

Delphi call breakpoint by :

    int 3;

  put is somewhere in the "beginning" of your project, for example in the DPR after begin. When Delphi stops there - CTRL + F2 to terminate the session and run again. This time it should be fine...
Cloud Class® Course: Microsoft Office 2010

This course will introduce you to the interfaces and features of Microsoft Office 2010 Word, Excel, PowerPoint, Outlook, and Access. You will learn about the features that are shared between all products in the Office suite, as well as the new features that are product specific.

I work several hours a day on a project that already has 464 forms and about another 70 code only units... it compiles smothly and I have never have the feeling of reaching any limit in Delphi7. May be some problems from time to time as mentioned, usually when debugging DLLs, but the average workday with delphi includes no errors at all... more oftenly it is windows explorer that will hang ;-)
464 forms? ... that's... scary.
DragonSlayer, 464 is a lot, BUT 90% of them use "visual inheritance", so there is "base form", with two more inherited forms (grid and record views of DB data tables), so most of those final forms have almost no code inside... anyhow, it a BIG app (6.33 Mb uncompressed).
ah... then in that case, that's not *too* many forms, hehehehe...

As for me, nowadays I'm using a slightly different method to re-use similar forms... e.g. for a form that displays some query results... let's say 1 for Customer query, the other (which looks similar, except for, perhaps the form caption and the ListView columns... and the query itself, of course) a let's say, Inventory query.

So I would design a form, with the ListView and everything there.

and in that form, I will make some procedures such as

procedure DoShowCustomer(AOwner: TComponent; const sCaption: string);
procedure DoShowInventory(AOwner: TComponent; const sCaption: string);

and in the procedures, the columns for the form will be dynamically created, the query, caption, etc will be done dynamically too.
This method you use is "obsolete"... imagine a TGenericShowRecord(sender) derived from a plain TFom, with a DoShowRecord method that show all the fields of the table (you just set a SQL property with the table stuff) but that is usually overloaded in most of your forms (let's say you have 200 forms to show 200 types of records)... if you play well with properties and method, you can finally have a TFromCustomer with just 10 lines of code in... the rest is common for all the Forms!

For instance, after having all those froms running, we added a new "Print Form" button to ALL of the 200 forms in 5 minutes... just added it to the generic form... THIS is powerfull! Thanks god we discovered it before coding this app!!!!!
geoffdbAuthor Commented:

>> [David] Stick to Delphi, you've got the best RAD product around !
Yes, while I've always thought that, my range of (tools) experience has been rather limited.   I got a bit caught many years ago with a largish project using C  ... but that's another story.

I was just concerned, as I can see quite a bit more time & effort going into this app, I did a count today and in fact I'm much closer to 200 pages of code than the 100 guessed at above - and that's in the main executable !!   So your collective assurances - and the explanation of the break point issue makes me much more comfortable.

The other thing that gave (and gives) me some cause for concern is the 'help' Delphi gives to hackers in terms of the function names being stored directly in the executable (refer, "Special on Delphi Reverse engineering").  

How have other people handled this ??.   OK, you don't use obvious names for "Password_Check" routines, etc, but it seems that hackers get a jolly good jump start whatever you do.  

Comments ?
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.