Actually there is no threading problem with the method that updates the progress of a progressBarControl because that method uses SendMessage function which is thread safe. So it it perfectly safe to do like this from any thread: clauses longOperation(...) :- ... % do something theProgressBarControl...

The problem in Progress Example 1 is caused by a bug in statusBarCell . But you can circumvent the bug by changing the order of the operations: implement projectToolbar ... clauses create(Parent) :- StatusBar = statusBar::newApplicationWindow(), StatusCell = statusBarCell::new(StatusBar, statusBarCe...

You should notice that it is difficult to deal with progress bars and long running operations. First of all the GUI thread must be active . If/while the GUI thread is performing long calculations the progressBar (and all other GUI) is frozen, and Windows will eventually mark the application as "not ...

To have a progressBarControl in one of the cells, you will do something like this (this is from the IDE code and there is probably things that you don't need): facts progress_ctl : progressBarControl := erroneous. clauses progressBarNew(Message, MaxCount) = ProgressBarId :- ProgressBarId = progressB...

If you have created and attached a status bar as described above you should remove it again. A standard GUI project comes with a status bar: implement projectToolbar open vpiDomains, vpiToolbar, resourceIdentifiers class facts statusCell : statusBarCell := erroneous. clauses create(Parent) :- Status...

It is obviously a bug that the compiler doesn't treat this correctly. And we will fix it (later ).

There are only two editions.

The differences can be found here Visual Prolog Editions Comparison.

The price is now €100.

Just out of curiosity, how did you discover this?

I find it very unusual to use unification like that. After all is just a more obscure way to write:

Thank you.

In the correct processing X is first bound and later compared

But unfortunately the operations has been exchanged, so that X is first compared and then bound.

Thank you. We will look at it.

Yes, it does. But the window window you are entering things in is a "goal" window. It interprets everything as a question/goal. To enter your own clauses you will put them in an editor window and consult the contents. I suggest that you go through: Fundamental Prolog Part 1 Fundamental Prolog Part 2

Yes, it is an example program, both in Personal and Commercial Edition.

This works fine:

The Commercial Edition is still sold (also on Sundays).

You have received a direct answer, concerning your purchase attempts. I am sorry for the inconvenience.

Objects (and predicates) cannot be saved and consulted. Well as you experienced they can be saved, but they cannot be consulted. There is a technical problem in dealing with cyclic and duplicate references between objects, but that could most likely be handled. But there is also a conceptual problem...