I have a list that shows that two source of information disagree, and human intervention is required to decide what to do about it. So I’m thinking there will be three areas of the screen: one which shows the disagreement (and where they can say what they have done about it), one which shows the info from one of the sources, and one which shows the info from the other source. One of those two sources is not too bad: about a half dozen fields and a little list with maximum seven items, but the other one is much larger. I currently have the information displayed on half a dozen tabs, and the user will actually need access to all of them to make a decision (they include a list of clients involved, addresses they have lived at in the past, historical notes etc.)
I think it is doable so long as people have a decent-size screen (the current version of the complicated screen is currently 1024 pixels wide).
My question is: is there an easy way to move the existing window with its tabs and so on, into the window with the other two chunks of stuff? I’m thinking that the easiest might be to start with the complicated window and add the other easier bits to it? The only user-modifiable data will be from the discrepancy table
Hi,
Not sure if I understood correctly, but some things I think can be useful to you about the UI:
- Instead of the complex source (with the half dozen tabs), you could use a simple LIST as a tree control, using the LIST’s attribute PROPLIST:Tree, showing a queue with several levels. This way, the root level will be the level 0, the tabs will be the level 1 and the info inside each tab will be at level 3, 4, etc… Also, the queue will need just 2 columns: a LONG column for the level (you can use a positive value for expanded and a negative value for contracted) and a STRING column for the info. I use it in a window with 6 or 7 levels of info, to show summarized and detailed (contracted) info at same time.
- You could use drag’n drop from sources 1 and 2 to the target area. Look in the help for the LIST’s attributes PROP:DRAGID and PROP:DROPID, and for the events EVENT:Drag and EVENT:Drop. I use it for dragging some record info from a window and dropping to another window
- So, you could have 3 windows: source 1, source 2 and target (the disagreement area). For drag’n drop you need just a little drop area visible in the target window to receive the EVENT:Drop. So the user can arrange the windows freely.
Hope this can help you a little bit. Just my .02
With the IDE from 7+ you can just select controls and copy then paste to another window.
It does work, I’ve done that a few times. Not does not work real well with control templates, only controls.
But @Flavio_Suarez idea of deconstructing into a list also seems like a simplification (From a User POV) and drag/drop or a couple of buttons to replace one with the other.
Yep, I was thinking about the UI (the user POV)…
About using the IDE, as said, copying the control templates will not work.
Additionally, you’ll have to copy/paste de variables used by the controls…
About the copy/paste of the window controls, you also can go to procedure’s properties > window source
Hi Flavio,
I think the tabs are necessary. There is just too much info, and some of the nodes would need to have hot fields by the side because there is too much info to put into a tree string.
What I currently have looks like this:
That blank area at the top will be for a comments box for the response. The tabs at the bottom right, probably the most important one (res_address) has four browses and a text box on it. Requests/payments (showing) also has four browses. The notes tab has a list and a big text box by the side.
I did find a bit of weirdness doing it. I started by copying the procedure that had the bottom right stuff in it. I made the window bigger and moved the existing sheet/tabs down to the bottom right. The fields on the first tab moved down with the sheet/tabs fine, but everything on the other tabs seemed to think their reference point was the top left of the window and not the top left of the tab, so I had to move all of them back to where they belonged. Other than that it all seems to work well.
Jon
I see. Too much info for a simple tree.
I also had these troubles with the window formatter some times…
Maybe using the keyboard to move the sheet would work better with the fields into the other tabs…
Are you solving the right problem? Why not just show a list of the differences with value1/value2/message and two buttons to access the original screens to fix the error?
Mainly because it helps to have both sources of information side-by-side to figure out whose information is wrong. If the housing agency says they are providing someone at a specific address with a housing subsidy then we should have the same person in that house marked as having subsidized rent.
Sometimes we don’t know they are receiving a subsidy
Sometimes the housing agency doesn’t know that someone has moved out
Sometimes the addresses don’t match
Sometimes the other information doesn’t match
Sometimes we have a completely different person at the address
It helps to have complete lists of clients from both sides, the address history from our side, access to any case notes on our side.
I often add a GROUP around all the controls using the Window … Editor. I’ll place that (X,Y) at the position of the Top Left control minus 2 DLUs.
Then in the GUI Designer move the Group, usually by changing its (X,Y) in the Property sheet, but it works to drag. That usually works perfectly. Probably want to Delete the Group when you are done. You MUST use the Window … Editor for the delete.
To Copy a Browse to another window … in short copy for Format() and #Fields() … in detail:
- In the Original procedure open the Window … Editor and Grab the LIST source complete with #FIELDS() and save in Notepad. Delete the #SEQ and #ORDINAL() to avoid mistakes later.
- In the New procedure on the Window create a Browse for the File with just 1 field so it creates a Browse template
- Save in the GUI then open the Window… Editor and find the new LIST
- From the Original copy in the FORMAT() and #FIELDS(). Do Not copy #SEQ or #ORDINAL, leave those as they were. #ORIG() can be deleted.
- That still leaves many other things like Hot Fields, Totaling, Buttons, etc to be done in the Template
Curious if your Window Previewer button works in Window Designer?
Right. I assume you have an audit process that looks for exceptions. The reason for the exception and the two values can be written to a memory table and browsed. You can launch the two existing detailed windows on separate threads and pass events to the threads to position at the correct point. The existing windows just need some added event and thread handling. It’s a lot less code to maintain.
Previewer works fine. One of the things it shows is the fact that big bolded text is not going to display properly. This is what the part of the screen looks like in the designer:
And this is what it looks like in the previewer:
Notice the difference with the big bolded NLHC data and IS data. NLHC data I changed the size to 14 bold, but kept the window font (Microsoft Sans Serif 8pt). The IS data as an experiment I also changed the font (to Microsoft Tai Le, which was the next thing on the font list). Not sure why the font attributes get ignored if you use the same font as in the window definition.
In theory I agree with you. In practice, not so much. Opening three windows rather than one from the browse and making sure they are correctly placed with respect to each other, and that each of the threaded files has received the value it needs so it knows what to display, and passing information back to the discrepancy window (for example, in one there has been no matching address found, and there is a browse to display potential matching addresses in the same postal code. If found the ID of that address would need to be passed back to the discrepancy thread).
Maybe it’s all easy, but if I have done something similar in the past I remember nothing about it. 
Duplicating a bit of code is not the end of the world, even if it is not ideal.