The parent objects are different.
In your manual image you have: VCLObject("f_PrintPreview_QT")
In your runtime image you have: VCLObject("f_PrintPreview")
They are not the same parent object (one has "_QT" the end, the other doesn't.). So have different children. (The entire child object tree is different!)
The parent of those controls - Window("MDIClient", "", 1) - also appears to be using an index number to identify itself. Thats never good. When it starts using index numbers, it does for a reason, in that it finds more than one but can't find any other way of telling them apart (automatic identification properties are by no means 100% perfect. Don't assume they will always work, all the time.). Avoid using them wherever possible.
How it's ending up in this position, I don't know. As a guess, I would say either:
1. Ambiguous object recognition of - Window("MDIClient", "", 1) -, causing it to end up with different child objects. As it's using an index, it's a definite possibilty.
and/or
2. You are doing something different at runtime so the objects produced are not quite the same as when you do it manually. Without seeing both processes, it's hard to say. It can be something as simple as the method you use to populate a field. If you are not setting a checkbox a certain way, or filling in a textbox - using Value() and SetText() methods is common ... I almost always use Keys() - wrong may not set off an event trigger in the code. Getting values into fields and checkboxes checked is half the battle. Getting them filled in and checked as close to how the user would do using the GUI - again - keys() vs SetText() - is the other half. Using native methods of objects to achieve things is often easy, but not how it happens when a user is operating the GUI.
They're my suspicions, but it's kind of impossible to say without seeing how you got into this position in detail.
