I've just reviewed one of the Visual Designer generated files.
I have fallen across this statement:
DEFINE PRIVATE VARIABLE components AS System.ComponentModel.IContainer.
Beside the fact, that it does not match our internal coding standards (no use of NO-UNDO and no comment describing why), shouldn't the visual designer add a NO-UNDO?
If there's no reason, I'll log it as a bug.
Maybe because of the object type?
Object references are un-done too:
oControl is not valid outside the un-done transaction.
True, but the other object is an interface.
What difference should that make???
The object reference is still un-done. Which means that every assignment to the variable will cause a slight overhead.
Have you tried looking at the impact on the .lbi from these statements?
I'm sorry for the confusion Mike. What I meant was that it could maybe have something to do with the fact that it is defined as an interface...
But the ABL MDI Form does have the same components variable defined as NO-UNDO. The only difference woth the ABL Form is that in the ABL MDI Form the components variable actually gets new'ed.
Omision in the ABL Form template?
No. Should I? Do you have any hint's why this should not cause unnecessary lbi activity - it can be un-done, so I guess there is activity in the local bi.
Must be something with the templates or the code generation process.
I've spotted this in an ABL inheritted control where it actually is not used. But I still don't see a reason why the variable should not have NO-UNDO. Well, actually I also don't see a reason for the variable to be there at all, but that's a differnt story.
Never the less, I logged it with tech support. I'll keep the forum updated.
Actually, I was assuming it would have an impact and wondering how noticeable it was.
It is a bug. It should have no-undo on it. Please report it to tech support.
Now, the reason for the components variable is that the code generation needs it sometimes. It is used for objects that need to be explicitly disposed. You'll notice that the destructor has code in it that explicitly disposes of the components object when it is a valid object. The components object is only instantiated on demand. The things that cause it to be created are other form components that require that they be disposed. This is normally the case for .net objects that access system level resources such as images.
Try this. Create a new empty form, and notice that the components variable is left unassigned. Now add an imagelist to the form, and you'll see in the generated code that the components variable is now assigned.
The imagelist object needs to be disposed since it manages images which are system level resources. If you don't dispose of images then you will potentially run out of GDI handles and you won't be able to create any more. The designer takes care of this by generating the code to dispose of the image list by adding the imagelist to the components object and disposing of a single object -- the components object. This is not restricted to image list. Any component can require that it be disposed of.