Replacing non-visual components with code

Question

Is "replacing non-visual components with code" a proven optimization technique in Delphi 7. Mostly with regard to access to the database.

Answer 1

The website you are quoting talks about replacing a dialog box component with code that displays a dialog box without using any component. An alternative is to write a couple lines of code to configure and display the dialog box whenever you need it, and generally skip the component. However, this is not an optimization in speed or size. This is not a speed optimization, since your code would do exactly what the component would do anyway, and this is not a size optimization, since the space occupied by any one component in the program is negligible.

Database components are not as easily replaced as dialog components. Almost everything in Delphi is designed to use descendants of standard database components. If you do not use components, then you will not use any features of the Delphi database at all. You can use your own database library APIs if you want, but I think it would be foolish if your goal were really optimized and you did not define the components as the source of the inconsistent behavior of your program. Think about how much time and effort it will take you to rewrite your program without database components.

Answer 2

I do not see how the data set is based on the form / query / table / etc. will be faster or slower than created in code. However, I like to introduce them into the code, as it is easier to maintain. I saw screens with SQL embedded in the component, and then it was redefined in the code. Then I have to stop and research to determine which SQL is actually acting. Sometimes SQL in a form is good, sometimes it is used for a while, and then pushed by the code, sometimes it is never active, and SQL in formcreate. So I have to determine if this is by design or just sloppy leftovers. In addition, it is easy to skip SQL changes in code reviews if they are in .DFM and not in .PAS. those. I don’t always look at .DFM, because I don’t care if the label has changed or the button is pressed.

So, while prototyping is good when it comes to production code, you better have all the database logic (SQL, tables, and field definitions) in your .pas file.

Update: I finally gave CnPack . Among dozens of goodies is a brilliant tool called "convert selected components to code." Form Wizard | More details ... | Convert selected components to code. He does everything for you.

Answer 3

It is not a question of being a component or not a component. If it comes to accessing the database, then BDE is very slow, so changing it for another is a good move.

By the way, optimization is not “proven methods” - it is a definition of a problem and its solution. If the problem is due to slow db access, then this is what you need to change.

Answer 4

Generally not. No additional overhead when using a non-visual component. It is created very quickly and runs at runtime at the same speed as "created in code".