|
| Changing Plane from inside an Internal Window |
| Iniciado por guest, 08,oct. 2015 08:52 - 3 respuestas |
| |
| | | |
|
| |
| Publicado el 08,octubre 2015 - 08:52 |
Two Issues:
1. My internal window is set to Plane = 0. I have a Static control set to Plane 1. In code I can change the Plane property of the Static to zero and that shows correctly. However if I try the same process with an Edit control or a Table Control then they do not show. Even though the Plane property has been change correctly. Any takers please?
2. From inside an internal window, I want to change the plane of the Internal window.
What syntax do I use? I am assuming that I need to address the Internal Window Control.
I know the name of the enclosing window and the internal window. However my attempts at indirection did not cause the items on the new plane to display
e.g. {sWindowName,indwindow}..Plane = 2 where sWindow will be something like "Win_Generic.IW_Empty"
I am assuming I am missing something obvious and I would really appreciate some insights from somebody who knows how to do this.
Thanks,
Steve. |
| |
| |
| | | |
|
| | |
| |
| Publicado el 08,octubre 2015 - 11:07 |
Steve
Not sure I understand the first point.
Controls not windows are set to planes (1 or more) - as you PageUp-PageDn on the window the controls assigned to the Plane (blue number top right) will be visible.
Controls without a specific plane will always be visible.
Recommendation (see Help) is that all communication to an internal window is via local procedures of the window.
I use the following...//Identify the current internal window and procedure lsIWProc is string = StringBuild("%1.lpModify",InternalWindow1..SourceWindow) SWITCH Tab1 CASE 1 //General Open(wCustomer,Param) //Standard window call OTHER CASE //Contacts ,Tickets, Assets, Accounts //Run the lpModify() procedure ExecuteProcess(lsIWProc,trtProcedure,Param1,Param2) END
Param 2 for example is the required plane number - code in the lpModify procedure effects the change.
You could of course just use IW name direct instead of formatting lsIWProc string - this code allows for a single IW control to service more than one internal window.
If you build each IW with the same set of procs a lot of your code can be pretty generic. |
| |
| |
| | | |
|
| | |
| |
| Publicado el 08,octubre 2015 - 11:57 |
Hi Steve,
From Inside a the actuall window:
Internalwindow..plane = NewPlane
From Outside, for example a ribbon button:
a Internal window seems to get the handle of the window containing it (or handle to the internal-window control)
I usually use Postmessage(handle(Main_Window),"CHANGEPLANE",NewPlane,0) From wherever.
In Main Window And in IW_MyWindow
Event("Someprocedure","*.*","CHANGEPLANE")
//Someprocedure can be empty in Win_Main
Someprocedure (wMsg,Wparam,Lparam)
IW_MyWindow..plane = wparam
//I tend to do a switch on wparam so I can do processing if Plane xx is choosed.
Cheers
Tor-Bjarne |
| |
| |
| | | |
|
| | |
| |
| Publicado el 09,octubre 2015 - 01:10 |
Thanks DerekT and Tor-Bjarne for the replies. They were helpful.
What I realise when reading the replies was that I was calling the procedure of the InternalWindow BEFORE the window had rendered. That was the issue.
See, I was wanting the Internal window to "initialise itself" into the correct state when it displayed. So I was calling the ChangeSourceWindow() Then my "InternalWindow.Initialiseyourself" procedure in the "After Initialisation" of the enclosing wiindow.
So, to fix it, I created a new Procedure called "AfterRender()" in my internal window.
This was then made to run automatically (by clicking the "1:30" icon on the Local Procedure bar at the top of the procedure code definition). I made it:
//// Automatic Procedure:
// The procedure is automatically run, after the window initialization code, with a delay set to 10 hundredths of a second
In that procedure I manipulate the Plane value for the Internal window.
The result is that the window renders with my table control from Plane 2 showing as expected!
I have seen issues like this before and never twigged to the point that my problem was that the GUI manipulation was not working BUT it had yet to render.
I need to let WD render the controls before (some of) the GUI manipulation will work.
I am thinking that this might be a good generic solution to these issues for the future in my framework mechanism.
Thanks again for the insights.
P.S. BTW I had never even considered using PostMessage() for this. That is the value of asking for help 
---
Steve H. |
| |
| |
| | | |
|
| | | | |
| | |
|