ChatGPT have created this answer:
What you are hitting is not really "OOP magic", it is mostly
scope + object vs class.
mydialog::radioButton_ctl means: "find a
class-level entity named
radioButton_ctl in scope
mydialog".
But your radio buttons are almost certainly
not class members. They belong to the
dialog object / dialog implementation context, so they are available inside the dialog’s own object predicates, but not as a public class member from outside. That is why the compiler says:
Undeclared identifier 'mydialog::radioButton_ctl'
In Visual Prolog, the implementation scope can contain private entities, and object members are accessed through the current object (
This) or through an object reference, not as arbitrary external names. The language reference also makes this distinction: class declarations expose the public part, while implementations may contain private entities; object members are invoked on an object, and inside object predicates the current object is available as
This.
So the practical rule is:
- Inside mydialog.pro: you can use the controls directly, because you are in the dialog’s own implementation/object context.
- Outside, in mytwo.pro: you should not try to access the control identifier directly.
- Instead, expose a public predicate on the dialog, and call that predicate on the dialog object.
A good pattern is this.
In the dialog interface/class, expose operations you want from outside:
Code: Select all
interface myDialog_i
predicates
setRadio1Enabled : (boolean State).
setRadio2Enabled : (boolean State).
setBothEnabled : (boolean State).
end interface myDialog_i
class mydialog : myDialog_i
end class mydialog
Then in
mydialog.pro implementation:
Code: Select all
implement mydialog
clauses
setRadio1Enabled(State) :-
radioButton_ctl:setEnabled(State).
setRadio2Enabled(State) :-
radioButton2_ctl:setEnabled(State).
setBothEnabled(State) :-
radioButton_ctl:setEnabled(State),
radioButton2_ctl:setEnabled(State).
end implement mydialog
Then from
mytwo.pro:
Code: Select all
clauses
somePredicate(Dlg) :-
Dlg:setRadio1Enabled(false),
Dlg:setRadio2Enabled(true).
where
Dlg is the dialog object:
Code: Select all
Dlg = mydialog::new(),
Dlg:setBothEnabled(false).
The important point is:
call the predicate on the dialog instance, not by trying to reach the internal control name from outside.
So, not this:
but this style:
or, if you really made it a class predicate, then a public class predicate such as:
However, for GUI controls this is usually an
object operation, not a class operation.
Why it works inside
mydialog.pro
Because inside an object predicate, Visual Prolog implicitly works with the current object (
This). The language reference explicitly states that object predicates have access to
This, and other object members can be called directly inside that context.
Why it fails outside
Because outside that object context,
radioButton_ctl is not a visible public class-level identifier. It is part of the dialog’s internal state/implementation.
So the mental model that usually helps old Turbo Prolog users is:
- Think of the dialog controls as private fields of the dialog object.
- From outside, never touch the fields directly.
- Ask the dialog to do it for you through a predicate.
If you paste the relevant parts of
mydialog.pro and
mytwo.pro, I can rewrite them into the smallest possible non-OOP-looking Visual Prolog solution.