Discussions related to Visual Prolog
rasvprolog
Active Member
Posts: 31
Joined: 1 May 2014 3:28

Send to Background-Bring to Top

Unread post by rasvprolog »

Dear Forum,
Happy New year to all.
I am invoking dialog B (diagnosis) from dialog A (consultation) by clicking on a "Ok" button. I have a "Cancel" button on dialog B for "what if analysis", so that when some one clicks on it, simply to send dialog B to the background(without any other effect) behind dialog A for latter view or comparison. I am using the following clause, but the problem is this re-initializes dialog A to the default values. Is there any clause just simply to send dialog B to the background without affecting dialog A . Thanks in advance.
Fred

Code: Select all

predicates     onCancelClick : button::clickResponder. clauses     onCancelClick(_Source) = button::defaultAction:-        _=consultation::display(getParent()).
FR
Harrison Pratt
VIP Member
Posts: 439
Joined: 5 Nov 2000 0:01

Re: Send to Background-Bring to Top

Unread post by Harrison Pratt »

Take a look at this in the IDE help:

vpi::winBringToTop/1

winBringToTop : (vpiDomains::windowHandle WindowHandle)
language c.

Brings the window WindowHandle to the front of the screen.

Description
Use the winBringToTop predicate to uncover any window that is partially or completely obscured by other windows.
The winBringToTop predicate brings the specified window to the top of the windows Z order. If the window is a top-level window, it is activated. If the window is a child window of a top-level window, this parent top-level window is activated.

Exceptions
vpi::vpi_winBadHandle/3
rasvprolog
Active Member
Posts: 31
Joined: 1 May 2014 3:28

Re: Send to Background-Bring to Top

Unread post by rasvprolog »

Thanks Harrison,
I have tried using that clause, but apparently I am not specifying the correct handle for the Parent window, so I get an error message. As an example when I modified my clause to:

Code: Select all

clauses     onCancelClick(_Source) = button::defaultAction:-        vpi::winBringToTop(getParent()).
I got compiling error: error c504 : The expression has type 'window', which is incompatible with the type 'vpiDomains::windowHandle'
FR
User avatar
Gukalov
VIP Member
Posts: 62
Joined: 5 Oct 2011 15:16

Re: Send to Background-Bring to Top

Unread post by Gukalov »

Look at "window.i":

Code: Select all

predicates     setActive : (). predicates     bringToTop : (). predicates     forceToTop : ().

For working with vpi there are:

Code: Select all

predicates     tryGetVpiWindow : () -> vpiDomains::windowHandle VpiWindowHandle determ. predicates     getVpiWindow : () -> vpiDomains::windowHandle VpiWindowHandle.
rasvprolog
Active Member
Posts: 31
Joined: 1 May 2014 3:28

Re: Send to Background-Bring to Top

Unread post by rasvprolog »

Hi Gukalov,
Per your feedback I modified my clause in dialog B to:

Code: Select all

clauses     onCancelClick(_Source) = button::defaultAction:-       % _=consultation::display(getParent()).         Win= getVpiWindow(),         vpi::winBringToTop(Win).
I think this gets the handle of the task window, as a result the program goes back to task window not dialog A that I want. As I have mentioned earlier, the order is as follows,1) dialog A is invoked by a menu item on the task window, 2) and dialog B is invoked by OK button on dialog A.
It is interesting to note that since dialog B is smaller than dialog A, I can achive my objective by clicking anywhere outside B on dialog A. I was hoping to be able to achieve that by clicking a Cancel button on dialog B.
Thanks
FR
Harrison Pratt
VIP Member
Posts: 439
Joined: 5 Nov 2000 0:01

Re: Send to Background-Bring to Top

Unread post by Harrison Pratt »

This might have an effect you desire -- just make dialogB invisible (or minimized) when you press Cancel.

Put this in dialogB:

Code: Select all

predicates     onCancelClick : button::clickResponder. clauses     onCancelClick(_Source) = button::noAction :-         This:setState([vpiDomains::wsf_Invisible]).

You will need to keep track of how many instances of dialogB you have created (you probably want to have only one) so dialogA knows whether to create a new instance of dialogB or just make it visible. I haven't tested making dialogB visible from dialogA, though.

I suspect that you should be using at least one form instead of two dialogs as forms are designed be be persistent visual objects and dialogs are (at the simplest level) point-and-shoot visual objects. I think your dialogB should probably be a form.

For an alternative approach, you might look at the tabControlDemo in the EXAMPLES. It might be a "less astonishing" visual effect if you have more than a very few users.
rasvprolog
Active Member
Posts: 31
Joined: 1 May 2014 3:28

Re: Send to Background-Bring to Top

Unread post by rasvprolog »

Thanks again Harrison.
Since the intention is what if analysis, there might be more than 4 or five instances of dialog B at a time. So when I set it as invisible they will remain invisible forever. Alternatively I have tried the following:

Code: Select all

predicates     onCancelClick : button::clickResponder. clauses      onCancelClick(_Source) = button::noAction:-       setState( [wsf_Minimized]  ),!.
it works fine but because there are so many instances of B, maximizing and comparing the dialogs becomes tedious.
Meantime I will try to see if changing the dialog to form will work better or not and will look at tabControlDemo.

Thanks
FR
Harrison Pratt
VIP Member
Posts: 439
Joined: 5 Nov 2000 0:01

Re: Send to Background-Bring to Top

Unread post by Harrison Pratt »

"so many instances of B, maximizing and comparing the dialogs becomes tedious."

Yes ... but you could put the B-dialog identifiers into a database (or a list in a mutable variable) in the A-dialog as you create them.

This might not correspond to what you are trying to achieve, but have you considered putting the functionality of B-dialog(s) into the A-dialog and making unused controls inactive (wsf_inactive) or hidden? That is easy to manage with lists of control IDs, too.
rasvprolog
Active Member
Posts: 31
Joined: 1 May 2014 3:28

Re: Send to Background-Bring to Top

Unread post by rasvprolog »

You are right eventually I might try something like that.
As is dialog B does not have any functionality, it only lists a easy to understand report in plain English from user's input by pulling the text from a database generated/captured based on user's input. In addition it dynamically lists the high probability diagnosis based on the 24 radiobottons, listboxes, checkboxes inputs. Maybe finally I have to try what you are suggesting. I was hoping there is a simple clause/predicate that will send an active dialog to the background (simulating what I acheive now by clicking anywhere outside the dialog box, which sends all instances of B to the background without minimizing or changing there size, for later comparison).

Best regards and thank,
FR
FR
User avatar
Thomas Linder Puls
VIP Member
Posts: 1398
Joined: 28 Feb 2000 0:01

Re: Send to Background-Bring to Top

Unread post by Thomas Linder Puls »

It sounds strange to me to have Cancel button that does not cancel the dialog.

However, it seems that the mentioned dialogs should be forms, see Dialogs and Forms.

Furthermore, it seems strange to keep "uninteresting" windows alive but sending them "backwards".
Regards Thomas Linder Puls
PDC
Harrison Pratt
VIP Member
Posts: 439
Joined: 5 Nov 2000 0:01

Re: Send to Background-Bring to Top

Unread post by Harrison Pratt »

Here's a suggestion from someone who knows nothing about the complexity of your project:

Create an internal fact database in dialogA and populate it with information to control what the user needs to see or wants to revisit. Put human-readable strings in the database that can be used to populate a listbox (multi-selection) to open relevant formB instances. Create an [Open Selected] button to open several at one time. Keep the window pointers for the opened forms in another area of the database so you can have a [Close All] button and destroy them with one click. You could modify some of the listbox display strings (e.g., append "*") to highlight interesting items, or present them sorted by diagnostic confidence or other pertinent parameter.

Setting certain listbox items "selected" (highlighted) could give the user some feedback on the current state of the diagnostic process.

Code: Select all

facts - formControlDB      fc : ( string UserPrompt, string FileToLoadInForm, ... <other useful info> ). % use this to populate listbox      openForm : ( string UserPrompt, window PointerToForm ).  % Assert for each form opened; use these facts to Close All
Fact databases make it very easy to extend functionality and control code complexity.
rasvprolog
Active Member
Posts: 31
Joined: 1 May 2014 3:28

Re: Send to Background-Bring to Top

Unread post by rasvprolog »

Thank you Thomas and Harrison,
I will follow your instructions to see if it helps.
In response to Thomas's question. The "cancel" button on dialog B cancel's the program as it suppose to do and brings Dialog A, but reinitializes it to default values.

Code: Select all

predicates     onCancelClick : button::clickResponder. clauses     onCancelClick(_Source) = button::defaultAction:-        _=consultation::display(getParent()).
To continue my explanation, it will be more clear if I change the title of "cancel" to "what if analysis", then you will see they are not uninterested dialogs. Each time the user changes the input in dialog A and gets an output in dialog B. By keeping the instances of dialog B alive and sending them to background allows the user (after testing several scenarios) to minimize dialog A and compare alive instances of dialog B. My original question was: is there a clause/predicate when I press the "What if analysis" button to go to Dialog A(consultation) without re-initializing it.

Best,
FR
FR
User avatar
Thomas Linder Puls
VIP Member
Posts: 1398
Joined: 28 Feb 2000 0:01

Re: Send to Background-Bring to Top

Unread post by Thomas Linder Puls »

bringToTop and setActive will both have that effect. The problem in your attempts (above) is that it is not A you are trying to bring to the top, it is the applicationWindow or B itself. Your dialogs should all have the applicationWindow as parent. So the question is how you will find the relevant A, and what you will do if A has been closed.

The obvious solution to finding A is to transfer it (i.e. This in A) to B, when A creates B, as an extra parameter in display and the constructor. The constructor will store the parameter in a fact in B, and when you press "what if" you call setActive on that fact.

Code: Select all

class b : b   predicates     display : (window Parent, window Creator) -> b TestForm.   constructors     new : (window Parent, window Creator).   end class b   implement b   facts     creator : window.   clauses     display(Parent, Creator) = Dialog :-         Dialog = new(Parent, Creator),         Dialog:show().   clauses     new(Parent, Creator) :-         creator := Creator,         ...   predicates     onWhatIf: button::clickResponder. clauses     onWhatIf(_Source) = button::noAction :-        creator:setActive().
This will however have no effect if creator has been closed.
Regards Thomas Linder Puls
PDC
rasvprolog
Active Member
Posts: 31
Joined: 1 May 2014 3:28

Re: Send to Background-Bring to Top

Unread post by rasvprolog »

Thank you so much Thomas for the thorough instructions.

Best,
FR
FR
rasvprolog
Active Member
Posts: 31
Joined: 1 May 2014 3:28

Re: Send to Background-Bring to Top

Unread post by rasvprolog »

Sorry Thomas, I thought I am going to march through it easily but...
I changed both dialogs to forms and followed the instructions. When I call (form b) from (form a) by clicking OK, using the following clauses, since (form a) has no idea about Creator, I get:

error e603 The flow pattern '(i,o)' does not exist for 'b::display/2->' a.pro

I tried to include Creator in display and constructor of(form a) as well, but the error shifts to the task window when I call (form a) from the taskwindow.

I do not know how to introduce or initialize Creator in (form a) or taskwindow to transfer to (form b).
Thanks

The following is in a.pro:

Code: Select all

clauses     new(Parent):-         formWindow::new(Parent),         generatedInitialize().   predicates     onOkClick : button::clickResponder. clauses     onOkClick(_Source) = button::defaultAction:-           _=b::display(getParent(),Creator).
FR
Post Reply