I still get the desired scroll bars but the size specified using %sz is neglected. I get similar results using %ww along with %'lw instead of %sh

Any ideas / pointers on how to achieve the desired result i.e. display of a quarter of the graphics area which I can move about using the scroll bars? There will be another child window along side with controls for the user to interact with.

Paul will be getting nervous as there are still some anomalies with nested child windows, reducing them, scrolling them, etc .... to sort out from quite a while back._________________''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... "

ClearWin+ does not have the concept of a child of a child in the sense implied by your code. %sh sheets are expected to be siblings with the same parent. In fact I suspect that ClearWin+ ought to generate a runtime fault when it encounters %ch after %sh (in the same window).

In my experience, if it seems difficult, it's because it might just be a non-standard (in the Windows sense) way of doing something, and the Windows way might be rather different (and possibly inferior).

Once you have an idea about an element in a graphics interface, it is worth looking around for another application that does it the way you want to. If you can't find one, it tells you a lot.

I couldn't get in-cell editing to work for me in a grid of data (I gave up ages ago), but I gained comfort from the fact that early versions of Excel couldn't either, and what it does now looks to me to be a compromise.

I've not used child windows before so I am on a learning curve, and experimenting.

For the long dark winter nights I have tasked myself with developing a schematic capture application for one of my programs which presently reads a power system configuration in as a netlist - which is always prone to error. Hence my earlier question last week about %gr selections.

Screenshot below is as far as I have got so far, with the graphics area displayed in one box and a collection of controls in the other. Obvious problem what happens with the network is too large to be drawn in the available space - hence I was trying to find a way to scroll the graphics, which led on to thinking about using child windows, and then to a child with its own child, which I now know is not a valid concept. No matter I have another potential solution - multiple pages and storing the active page number when an item is drawn (all data for each item is a derived type) and a special component to link two nodes on separate pages.

Ken,
your code as it's set up is trying to put a sheet in a sheet. I think that's what Paul means by it's not intended to do it as you're trying to set it up.

I think you ned to set it up via a frame (%fr) within the main window and then open a child window (%aw), with a %sh to get the control bars; and similarly for the seecond window you need, but without the sheet if you don't need one.

It's a problem of logic I think, not an impossibility to do it._________________''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... "

It is worth noting the you can use the existing %hx and %vx to attach scrollbars to the next control (for example %gr). Then a callback that is attached to %hx and %vx can be used to provide feedback in order to set the origin of the graphics object that is to be drawn to %gr. It would work well for a click on a scrollbar but dragging the scrollbar "thumb" may prove troublesome.

Scrollbars are one method of moving the image relative to the window. An advantage of them is that people know how to use them, a disadvantage of them is that they only provide a mechanism for panning, and not for zooming.

If the object(s) in the display have real-world coordinates as well as pixel coordinates on the screen, then you need mapping functions, not least because the screen coordinates increase downwards whereas most real-world objects have coordinates in the upper right quadrant so that the vertical coordinate increases upwards. The mapping function will have a scale factor, and a very easy way to perform zooming is to read the scroll wheel and change the scale factor, then redraw. It will also have ‘shifts’, which I always arrange so that the centre of the region I want to show lies in the centre of the %gr area.

Another way to zoom in or out is to enable the box selection (via menu selection or toolbar icon), and get the box corner coordinates from which the scale factor can be recalculated before redrawing. Restoring two fully zoomed out conditions can be done again via a menu selection or a toolbar icon, or by reading one of CTRL, ALT or SHFT with a mouse click.

If you do have scrollbars then having read the change in position then it is a matter of obtaining new shift values and then redrawing. You can also get a pan which works well if you changing the cursor to a ‘hand’ and then as the user drags it, change the shifts and redraw. A thing to remember is that the shifts you get from the dragger hand are of a different sign to those from scrollbars. You may need to select the dragger hand from a menu or toolbar icon.

If the hx and vx scrollbars aren't to your liking, you can create your own with extra %gr areas.

I adapted the Tektronix Plot10 software to have a virtual %gr region, which maps onto a real %gr region, by mapping the
selected screen centre and scale_factor to the real screen.
( I actually have multiple virtual layers, each with their own (x,y, factor) which copes with 3D to 2D transformations )

You can have a number of options ( which you now have as selectable in your menu ).
My options include:
# Pan ( I hold down the left mouse and drag, dragging the latest real image over the visible screen )
# zoom in/out (of centre of the screen or where mouse was last clicked, like google maps )
# zoom to selected area (by selecting a new rectangle with set_graphics_selection@ (1) I don't allow x-y distortion)

Most of my options work by selection an option state then actioning by responding to the mouse clicks.

Your latest example looks very good, which shows you can achieve useful informative displays with just a few commands.

You might also consider a "pop-up child window" to display a selected model object.
This is not a new %gr window, but just a rectangle you define in the %gr window, which you update with new graphics info,
after saving the previous rectangle info, then restore when this selection is completed.
I simply redraw the model in this new rectangle with revised x0,y0 and scale_factor so only the highlighted area is seen;
like a magnifying glass.

Eddie is right in that you need to consider past expected responses, but just a few simple capabilities are very useful for model review.

Screen dumps to .png files are also very useful for including this info in a report. .png files can be easily imported into a .docx file
and can be easily scaled. Sizing text in the .png file can be an issue for reports so you might want a text size option fir the screen display as text is just graphics in a .png file.

Thanks Paul, Eddie, and John for the suggestions. I had originally thought about a zoom function – but decided it was too hard – but it’s back on the too do list. Unfortunately I will have to revisit the subroutines that draw each type of object to achieve this. This is really the first time I have tried to do anything interactive in a graphics region – everything I have done todate has been static – so I am on a learning curve (1 step forward and 2 backwards). Another thought would be to replace the buttons that list the components with a %gr region that shows components graphically – the buttons were a quick way to get started.

I’ve spent the last few days thinking about the problem of scanning the diagram and converting that to a network connectivity. I’ve got that working now, and can assign numbers to each of the nodes in the diagram (elements connected by an ideal link are the same node electrically), so now I have all the data necessary to populate the system admittance matrix. The link below shows the node numbers displayed on the diagram – which has also got me thinking about how best to display calculated results i.e. voltages and line flows on the diagram (a zoom function would be very good, and colours to show over/under voltages or currents exceeding thermal limits of equipment). It will keep me out of mischief.