4 Predicates

manpce
manpce(+What)
Start the XPCE online manual tools. Without arguments, this just opens the PCE Manual main window. If the argument is the name of a class, it will start the ClassBrowser on this class. If the argument describes a method or variable, it will open the CardViewer on the described object. Syntax:

class -> send_method Describes a send-method
class <- get_method Describes a get-method
class - variable Describes an instance variable

For example:

?- manpce(button->message).

will start the CardViewer on this method. See also editpce/1.

new(?Ref, +Class)
Create an instance of Class, using its arguments as initialisation arguments. Ref is unified with the newly created object reference. See also pce_global/2.
send(+Object, +Message)
Invoke a send-method on Object. Object is processed as the initialisation arguments described with new/2. This implies that a complex term is translated into an object before the method is invoked. An atom is translated into an XPCE name object. Message is an atom or complex term. The functor defines the selector: the name of the operation to invoke. The arguments are processed as the initialisation arguments described with new/2.

Sending a message is composed of the following steps:

If all these steps succeed and the implementation succeeds, send/2 succeeds. If anything fails, an error is raised through object->error. If the error has error<-feedback: throw, a Prolog exception is raised; otherwise XPCE itself reports the error.

See also get/3, send_class/3, send_super/2, new/2 and free/1.

send_class(+Object, +Class, +Message)
Like send/2, but the implementation of the indicated Class (possibly inherited from an even higher class) is used rather than the implementation of the class to which Object belongs.

Class must be a super-class of the class to which Object belongs.

This construct is normally not used directly. Instead, send_super/2 should be used, which is translated at compile time to a proper send_class/3 call.

send_super(+Object, +Message)
The goal send_super/2 is actually not a predicate: it can be used as such in the context of a method declaration (see :->/2) and is expanded by the class-compiler into an appropriate send_class/3 call. Example:
:- pce_begin_class(myapp, frame).

initialise(A) :->
    send_super(A, initialise, 'My 1st application'),
    send(A, append, new(D, dialog)),
    ...

See also send_class/3, send/2 and get_super/3.

send_list(+Ref, +Selector)
send_list(+Ref, +Selector, +Arg)
The utility predicate send_list/[2,3] is similar to send/[2,3], but any of the arguments may be a list. For each member of the Cartesian product a message is sent:
send_list([Box,Circle], pen, 2).

is equivalent to

send(Box, pen, 2),
send(Circle, pen, 2).

send_list/3 is often used to append menu items to a menu:

send_list(Menu, append,
              [ menu_item(quit, message(@arg1, free))
              , menu_item(hide, message(@arg1, hide))
              ]).
get(+Object, +Message, -Answer)
Like send/2, but where send-behaviour acts as a boolean procedure, get/3 acts as a function: it requests a value from the receiving object.

In general, get-behaviour does not modify the object base, with the possible exception of creating new instances that serve as the answer to the query. Send-behaviour is intended to modify the receiving object; nothing in the implementation enforces this, and some get-behaviour has side-effects beyond creating the answer.

The answer of get-behaviour can be an attribute of an object (e.g. graphical<-area returns the area object associated with the graphical), or it can be a freshly created object (e.g. graphical<-size returns a new size object reflecting the size of the graphical). The documentation is the only source for this detail.

Knowing this can be important. For example, modifying the size object returned by graphical<-size is valid but does not affect the graphical. Modifying the area returned by a graphical however will leave the graphical in an incoherent state.

Under normal circumstances, there is no need to ->free the object returned by a get-operation. If the object is not referred to, it will automatically be discarded by the incremental garbage collector once its scope of creation ends.

See also get_class/4, get_super/3, get_object/4 and get_chain/3.

get_class(+Object, +Class, +Message, -Answer)
Invoke get-methods inherited from Class rather than the implementation belonging to the class of Object.
get_super(+Object, +Message, -Answer)
Like get/3, but uses the implementation of the super-class of the class to which Object belongs. Translated at compile time to get_class/4.
get_chain(+Ref, +Selector, -List)
Utility defined as
get_chain(Ref, Selector, List) :-
    get(Ref, Selector, Chain),
    chain_list(Chain, List).
get_object(+Ref, +Selector, +Args, -Term)
The utility predicate get_object/[3-13] is similar to get/[3-13]. Where get/[3-13] normally returns an object reference, get_object/[3-13] by default returns a term similar to object/2. Used mostly for debugging from the interactive toplevel.
chain_list(+ChainRef, -List)
Translate an XPCE chain into a Prolog list. This may be useful to exploit Prolog's list-processing primitives. Note however that XPCE chains define various operations that may be exploited to avoid the translation. See chain->for_all, chain<-find_all, etc.
free(+Ref)
Send ->free to Ref if it is a valid reference. Defined as
free(Ref) :- object(Ref), !, send(Ref, free).
free(_).

This definition implies free/1 only fails if the object may not be freed (see object->protect).

object(+Reference)
object(+Reference, -Term)
The Prolog predicate object/1 is an extension of the Prolog type-test predicates. It succeeds if Reference refers to a valid object reference -- a term of the form @/1 whose first argument is an atom denoting the name of a global object, or an integer referring to an existing object.

In all other cases this predicate fails silently. Note that, if the term is of the form @<integer>, heuristics are used to determine whether the indicated memory location refers to a valid object.

object/2 converts an object into a descriptive term. See the User Guide for complete information.

See also @pce<-object_from_reference and object->name_reference.

portray(+Ref)
Like portray/2; prints on the terminal.
portray_object(+Ref, -Term)
Like object/2, but heuristically expands arguments.
default(+Arg, +Default, -Value)
Handle default arguments in methods. default/3 is only used inside a user-defined method declaration. It specifies the value of an omitted (default) argument. If Arg is not omitted its value is returned in Value; otherwise Value is unified with Default.

Default may take the form

resource(Object, ResourceName)

in which case Value will be bound to the result of object<-resource_value: ResourceName.

Note that the message-passing kernel passes omitted arguments as @default. Example:

image(R, I:[image]) :->
    "Set image of object"::
    default(I, image('pce.bm'), Image),
    ...
checkpce
Validate the internal consistency of XPCE's database. It checks for:

The predicate succeeds if no errors were found and fails otherwise. Error messages are written to the host-language window. See also object->_check.

pcerefer(+Ref)
Scan the XPCE object base for objects that have references to Ref. Most commonly used in combination with checkpce/0: if checkpce/0 reports an object to be in an inconsistent state, pcerefer/1 can analyse its context.
in_pce_thread(:Goal)
Post Goal to the thread running XPCE. This supports XPCE running in a foreground thread (handling the GUI and short application-oriented actions) while one or more background threads do computation and other background work. Background threads call in_pce_thread(Goal) to insert a Prolog goal into the main thread's event loop -- the goal is placed in the normal X11/Windows event queue. in_pce_thread/1 returns immediately in the calling thread.

A typical setup has the background thread compute a result and ask the GUI to present it. The result may be passed as an argument to Goal or held in dynamic predicates. Both threads run in parallel, so update/read of shared dynamic data must be properly coordinated. To wait for the GUI to complete the calling thread can use a message queue:

sync_call(Goal) :-
    thread_self(Me),
    in_pce_thread(make_sync_goal(Goal, Me)),
    thread_get_message(sync_goal(Result, Binding)),
    (   Result == true
    ->  Goal = Binding
    ;   Result == exception
    ->  throw(Binding)
    ).

make_sync_goal(Goal, Thread) :-
    (   catch(Goal, E, true)
    ->  (   var(E)
        ->  Msg = sync_goal(true, Goal)
        ;   Msg = sync_goal(exception, E)
        )
    ;   Msg = sync_goal(false, _)
    ),
    thread_send_message(Thread, Msg).
pce_open(+Object, +Mode, -Stream)
Open an XPCE object as a Prolog stream so the normal Prolog I/O predicates can read from or write to the object.

Works on any object that implements the *_as_file methods. Currently those are the subclasses of class source_sink:

In addition, the following methods provide partial support: char_array<-read_as_file, char_array<-size_as_file and stream->write_as_file.

The stream handle is discarded with Prolog's close/1 predicate. For example, to write to a view:

pce_open(View, append, Stream),
format(Stream, 'Hello World~n', []),
close(Stream),

See also text_buffer->format. Reading from a stream is used by PceEmacs to verify the syntax of an entered clause.

pce_server(+Address)
Create a socket-based server. This predicate is in library(pce_server). It creates a server-socket object at the specified address which other processes can connect to in order to give Prolog commands to this XPCE image.

pce_server/1 implements a simple generic server. Its sources may be used as a starting point to write dedicated servers. The Unix command xpce-client may be used to connect to XPCE sockets. Below is an example of using this library:

% xpce
<banner>
?- pce_server(gnat).
yes

% on another terminal on the same machine
% xpce-client gnat
(pce) send(new(P, picture), open).
P = @364728
(pce) exit
%

The reserved command exit closes the server socket -- only this connection.

pce_image_directory(+Spec)
Define an alternate directory containing images. Modifies the image.path class variable, adding the path Spec expanded through Prolog's path-specification mechanism to the image search path. See also image->load, image->initialise and image<-convert.

It also prepends Spec to the file_search_path/2 specification for image. Normally used as a directive.

pce_catch_errors(+Id, +Goal)
Handle XPCE errors raised while Goal is called. Id is either the id of an error object or a chain of such ids. If one of the listed errors occurs the goal silently fails and @pce<-last_error holds the id of the trapped error. Any other error encountered while Goal runs is handled by XPCE's normal error-handling mechanism.

Exceptions are repairable errors. Exception handlers may be installed in @pce<-exception_handlers.

pce_global(+Ref, +Pred)
Declare a predicate that creates the object referred to as Ref. Part of XPCE's facility to create objects only when they are actually needed: this keeps start-up time short for large applications.

The first argument is the global reference being declared. The second is either the name of a predicate capable of creating the object, or a term wrapped in new/1 representing the object.

Examples:

:- pce_global(@center,
              new(spatial(xref = x+w/2, yref = y+h/2,
                          xref = x+w/2, yref = y+h/2))).

:- pce_global(@pce_icon, make_pce_icon).

make_pce_icon(Ref) :-
    new(Ref, bitmap),
    send(Ref, load, 'pce.bm').
pce_autoload(+Class)
Autoload Class if it has been declared via the pce_autoload/2 directive. See also pce_autoload_all/0.
pce_autoload_all
Autoload every class declared for autoloading. Normally used before qsave_program/2 so the saved state includes those classes.
auto_call(+Goal)
Make an autoload call, even on Prolog systems that lack this facility. Prolog systems with autoload define this using call/1; others can use pce_require/1:
auto_call(Goal) :-
    functor(Goal, Name, Arity),
    pce_require([Name/Arity]),
    call(Goal).
pce_require(+ListOfPreds)
Declare that this module requires the predicates listed in ListOfPreds -- a list of Name/Arity pairs. Together with auto_call/1 it is part of XPCE's portability layer.

Prolog systems with a library-predicate autoloader provide an empty definition for this predicate. Other Prolog systems can search the library index and call use_module/2 to import the predicates.

pce_begin_class(+Term, +Super)
pce_begin_class(+Term, +Super, +Doc)
Start declaration of a class. Together with pce_end_class/0 (or pce_end_class/1) this directive brackets the definition of a Prolog-defined class. A Prolog source module may contain any number of these pairs, defining any number of XPCE classes.

Term defines both the class name and the term structure when an instance of the class is transformed into a Prolog term. The term has the form

+Class(...+Selector...)

where Class denotes the class name and the optional list of selectors gives the (argument-free) get-behaviours used to obtain the arguments of the term representation. See Object->Term.

The description term may be prefixed with the meta-class to be used. For example, the following declaration ensures the meta-class is my_meta_class:

my_meta_class:myobject

Super is the name of the super-class. It must be the name of a defined XPCE class or a class declared via pce_autoload/2.

Doc is an approximately 40-character summary documentation string visible in the manual tool.

pce_extend_class(+ClassName)
Prepare for the declaration of methods on an already existing XPCE class. Be careful when extending built-in classes: it is easy to corrupt the internal consistency of the extended class or one of its subclasses. The class extension is terminated with pce_end_class/0.
pce_end_class
pce_end_class(+Class)
End declaration of a class. pce_end_class/1 finishes the definition of a class opened with pce_begin_class/[2,3] or pce_extend_class/1 in the same way as pce_end_class/0, but provides additional documentation and error checking and is recommended over pce_end_class/0.
pce_class_directive(+Goal)
Execute a directive on the constructed class. Used between pce_begin_class/[2,3] and pce_end_class/0 to invoke additional behaviour on the defined class.

XPCE classes are not created immediately when a Prolog file holding a class definition is loaded. Instead, the specification is translated into Prolog facts; if a reference is later made to the class, the XPCE class counterpart is created. This means it is not possible to invoke behaviour on the class being defined using ordinary Prolog directives.

A goal declared with pce_class_directive/1 is stored with the Prolog class definition. When the class object is actually created the declared class-directives are executed. During the execution @class is a var object referring to the class being built.

The preprocessor automatically tags directives of the form :- send(@class, ...) with this directive.

pce_group(+GroupName)
Start a functional group of methods. Used between pce_begin_class/[2,3] and pce_end_class/0 while defining an XPCE class.

Method declarations following this directive get the specified group identifier, which gives a better overview of the class through the manual tools (ClassBrowser).

The value @default (pushed by pce_begin_class/[2,3]) assigns a method to the same group as an inherited method of the same name, or the group miscellaneous if no such method exists. The directive has no semantic implications.

See also pce_begin_class/[2,3], pce_extend_class/1 and method<-group.

class_variable(+Name, +Type, +Default)
class_variable(+Name, +Type, +Default, +Doc)
Declare a class-variable. The term class_variable/[3,4] is expanded by the XPCE class compiler and associates a class_variable object with the current class.

This declaration supersedes resource/4. Unlike with resource/4, Default is a term that is translated as the arguments to send/[2-12].

resource(:Name, +Class, +FileSpec)
Define data for a resource. Used as a directive while declaring a class.
variable(+Name, +Type, +Access)
variable(+Name, +Type, +Access, +Doc)
Declare an instance variable. Normally placed immediately after the pce_begin_class/[2,3] call to declare the additional slots (attributes) of the class. The arguments are:

See also class->instance_variable.

handle(+X, +Y, +Kind, +Name)
Declare a handle for this graphical. Attaches a handle object at the class level when between pce_begin_class/[2,3] and pce_end_class/0. See also class->handle.
delegate_to(+Variable)
Add the indicated instance variable to the list of delegate variables of the class (see class<->delegate). Expanded by the XPCE/Prolog class compiler.
use_class_template(+TemplateClass)
Import methods from TemplateClass. Provides a simple mechanism for sharing method and variable definitions across multiple classes.

Suppose an application requires specialisations of several primitive graphical classes. Three ways are available: use pce_expand_class/1 on one of the super-classes (unsafe, as the methods become available to all users), make subclasses of every class needing the extension and duplicate the source (bad: hurts maintenance), or use a class template.

To use a template: first create a subclass of class template and define all variables and methods that need to be attached to the target class. Then write:

:- pce_begin_class(mybox, box).
:- use_class_template(my_graphical_extensions).

:- pce_end_class.

This behaves exactly as if all text defining my_graphical_extensions were duplicated at the use_class_template/1 call. The method implementation (the Prolog predicate) is shared between the classes that use the template.

Note that you can normally not create instances of the template class itself since it may lack methods that need to be refined in the target classes. Note also that you cannot further refine a method imported from a template in the same class -- the import behaves like text duplication, so a new definition simply overwrites the one from the template. You can refine the method in a subclass.

editpce(+What)
Start PceEmacs on a method or class. Works only for classes and methods defined in Prolog, unless run from a system with the XPCE C-sources installed. Syntax:

classname Edit the class
class->send_method Edit a send-method
class<-get_method Edit a get-method
class-variable Edit the class that defines the variable

For class-variable, if the variable is inherited from the specified class the editor opens on the class the variable is inherited from.

tracepce(+Behaviour)
Trace the indicated behaviour object. Puts a trace-point on the behaviour so the system prints entries and completion of that behaviour. Behaviour is specified as class->selector or class<-selector. Example:
?- tracepce(box->event).
Trace method: graphical ->event

See also spypce/1 and breakpce/1.

notracepce(+Behaviour)
Remove an XPCE trace-point. See tracepce/1 for details.
breakpce(+Behaviour)
Put an XPCE break-point on a method or variable. Functionality is like tracepce/1, but the system breaks into the interactive tracer when the behaviour is called. See also program_object->break, spypce/1 and nobreakpce/1.
nobreakpce(+Behaviour)
Remove an XPCE break-point. See spypce/1 for details.
spypce(+Behaviour)
Put a Prolog spy-point on the implementation of an XPCE behaviour. Behaviour is of the form class->send_method or class<-get_method. The predicate locates the method, determines the Prolog predicate implementing it and calls spy/1 to put a Prolog spy-point on that predicate.

Can only be used on methods defined using the Prolog class definition mechanism realised with pce_begin_class/[2,3] and pce_end_class/0. See also tracepce/1 and breakpce/1.