What's best to use?

In planning out a new feature, I have some questions for anyone who cares to comment.

I have several data items that will be displayed. Data items will be displayed next to each other, although the spacing between items may be different. Each data item will have a consistent width, and its own height. The data item will be drawn as a strip using mostly color changes to distinguish changes in the column, but also may contain text/numbers/lines/.... The user will wish to move the item up/down using the mouse. Portions of the item may not be displayed because the item may be bigger than the window can contain (and visually clipped); that is, they will be higher than the top of the window, or lower than the bottom of the window.

I played around using a child window but this seems to be a poor choice. Resizing the parent causes the child to 'reset' its position (undesirable). A resize is forced if I programmatically move the child window outside the parent's visible area.

I thought about using an image (the code that normally draws these items for a printer can create a BMP/JPG file), but positioning an image is done by ????.

I am leaning toward using the drawing surface (%gr) and, as the user uses the mouse to drag an item up/down, just redrawing the entire visible surface.

It is possible that an image area can be created (get_bitmap_dc()) into which all the items can be drawn, then have the bitmap displayed at the appropriate (x,y) offset.

There may be other possibilities I have not considered.

The description sounds very much like a borehole log, of which only a small part is visible at a time.

I would use %gr, but with a %vx scroll bar. The various parameters for %vx would need to be evaluated from the overall depth of the log, the height of the %gr and how much of the log is visible.

Assuming that your description of printing the object and having the code already, then of course you can plot the whole lot into the %gr area and let the automatic cropping facility of %gr simply not plot the bits that don’t show. If you have a ‘mapping function’ to map the real object including scaling and shifting, then the feedback from the scroll bar affects the shift and not the scale – you would need a different control to affect the scale (i.e. to zoom)- perhaps a slider control.

An alternative to using a scroll bar is to drag the contents with a ‘grabber hand’, which normally requires changing the cursor and reading the mouse button states. The description you gave looks more like a case for the scroll bar than for the grabber hand. It also doesn’t sound like you want to zoom to a block selection either.

Eddie

Eddie, great zeroing in on the borehole. Yes, they are borehole records.

I resist using scrollbars, although if they were narrow enough, they would be usable. Even with today's screens resolution and wide and multiple, you can only get so much data to display.

My users have definite ideas about what will/won't work. Still, scrollbars are a great idea.

Sometimes they want to place the data in relative position, meaning the distance between the data is relative to placement in the window. Zoom is not done by changing the width of the image, rather it changing the apparent scale (pixels/foot or pixels/meter, depending on the user's preference). When this happens, I still have to maintain the relative 'Y' position if they have manually correlated the data they wish to see.

The drawing of the items is very quick, so redrawing the individual images will be very fast. There will also be a practical limit to how many items are visible at any one time. My users tell me that trying to correlate more than about 12 items (manually, using printed materials) is very labor intensive.

Bill

How English speaking people understand each others is beyond me. After encountering word 'borehole' i gave up to understand anything. 😃)))

They are trying to describe GUI with the words. It's the same as describing music with the ascii symbols 😃

I'd Google 'GUI Examples' and in the section 'Images' chose the ones which more or less fit. Posting the images here would have an effect that Paul may pre-design them so that you just change the names and pre-loaded functions with your own

https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcQDL6fHqqD8LFEMYohDAC1qboHNwWXzmnGl-g&usqp=CAU

Bill

Is there an existing App that does something like what you want so that I can visualise it?

Does the data to be displayed consist of text only?

I am thinking in terms of a list box with a child window alongside it that displays the data for the item selected in the list.

I have used bitmaps defining electrical circuit elements and ADD_GRAPHICS_ICON@ in my simple “schematic capture” program. This allows the user to add a component, move it around, and then add “connection wires”. In this case, the Icons/bitmaps are added to a program via the resources section of the code. There is a snap function so that the connection points sit on the correct position of an imaginary grid.

If it were possible to create the required bitmaps within the code (which is something I have not investigated but thought about trying in the past), then the functionality that Bill is requesting could perhaps be achieved using ADD_GRAPHICS_ICON@

So a question for Paul: Is ADD_GRAPHICS_ICON@ restricted to icons/bitmaps in the resources section?

Ken

Sorry Bill, I wrote %vx when I meant %vy.

Scroll ba5rs are typically about 20 pixels wide (on the SF forum) so 12 of those would make 120 pixels. My monitors are 1920 pix wide, so allowing for borders, and a further 20 pix between each ‘object’, we’d have to allow 130 pix, making 250 or a bit more with frames and borders on the window, say allow 300 overall, leaving 135 pix for each object. That would be more than enough for a graphical depiction of the strata within the borehole, but is very little for any text. You could easily put a scale and a coloured or textured log in that width, and have a much bigger box for the textual description if you made some form of selector which ‘activated’ one log at a time.

I have drawn my suggestion which takes the form of a 14k PDF – if you PM me an address I’ll e mail it.

Eddie

Dan,

Do you want instructions on telepathy, or how to use an Ouija board?

Seriously, it became obvious to me from a range of Bill's previous posts that his main app is something to do with oil/gas exploration, and the obfuscated description wasn't all that obfuscated!

Eddie

Here's a link to a sample startup image of the current Java application. I have no access to the original code, just the runtime. I'm using this as a starting point for capabilities and features, not necessarily presentation and underlying data structures. The data from which these columns are created are managed by my software product.

https://capture.dropbox.com/JP2CiPdCsdUTjEXF

In this first image all the boreholes are set to the same start point but have different elevations (top orange bar). The user can drag the logs up/down to change this to set all the logs to the same reference elevation. The text within the column shows the rock type (also color coded).

In this example, some of the logs were dragged to have the same elevation at the reference line, and the image of the rock type is superimposed (no colors).

https://capture.dropbox.com/gTbHRPlLaxyvcPRj

There are a few display options (not shown here) and I want to add more options to assist the user. The original software developer ( a student) did a great job on this, but did not understand all the data available. I'm going to take advantage of what is in the data!

I have played around with OpenGL with not enough success to continue down that path, although it hold more promise for added features than does a 2-D window.

Ken

ADD_GRAPHICS_ICON@ is currently restricted to icons and bitmaps. The corresponding Microsoft primitives that are used are DrawIcon and BitBlt.

In theory it should be possible to extend this to other image types that have corresponding primitives (perhaps by using the GDI+ library).

Paul,

Thanks for the information. I did not form my question very well.

If the bitmap does not exist in the resources section but is instead created during the execution of the program, can it then be attached as an icon?

Something like this:

program test
use clrwin
implicit none
integer :: gw = 400, gh=400
integer iw, control, x,y
integer(7) :: i7

! Create a new bitmap within the program   (20 x 20 red box in this case)
iw = winio@('%gr[red]&',20,20)
iw = winio@('%lw',control)
iw = export_image@('bitmap.bmp')
control = 0
call window_update@(control)

! Create main window and attach the new bitmap as movable icon
iw = winio@('%mn[Exit]&','Exit')
iw = winio@('%gr&',gw,gh)
iw = winio@('%lw',control)
x = gw/2
y = gh/2
i7 = add_graphics_icon@('bitmap.bmp', x,y,20,20)  ! This does not work as the bitmap did not exist before the 
                                                  ! resources section was compiled.
                                                  ! add_graphics_icon@ is looking for a resource name from the
                                                  ! resources section, rather than a file name.
                                                  ! Is there a way to attach the new bitmap created by the program
                                                  ! to the %gr region as a movable icon.
end program test

!resources
!mybitmap BITMAP bitmap.bmp

Ken

You can use curly brackets...

i7 = add_graphics_icon@('{bitmap.bmp}', x,y,20,20)

Paul,

Thanks for that suggestion - I don't think that has found it's way into the documentation for add_graphics_icon@.

Bill,

This illustrates the basic idea I was thinking about for your case:

program test
use clrwin
implicit none
integer :: gw = 400, gh=400
integer iw, control, x(2),y(2)
integer(7) :: i7(2)
integer(7) cb
external cb
common /coord/ x,y

iw = winio@('%gr[grey]&',40,200)
iw = winio@('%lw',control)
call bold_font@(1)
call draw_characters@('1',20,20,rgb@(0,0,0))
iw = export_image@('bitmap1.bmp')
control = 0
call window_update@(control)

iw = winio@('%gr[grey]&',40,200)
iw = winio@('%lw',control)
call bold_font@(1)
call draw_characters@('2',20,20,rgb@(0,0,0))
iw = export_image@('bitmap2.bmp')
control = 0
call window_update@(control)

! Create main window and attach the new bitmaps as movable icon
iw = winio@('%mn[Exit]&','Exit')
iw = winio@('%^gr&',gw,gh,cb)
iw = winio@('%lw',control)
x(1) = gw/2
x(2) = x(1) + 60
y = gh/2
i7(1) = add_graphics_icon@('{bitmap1.bmp}', x(1),y(1),40,200)
i7(2) = add_graphics_icon@('{bitmap2.bmp}', x(2),y(2),40,200)
end program test

integer(7) function cb()
use clrwin
implicit none
integer y(2),x(2)
common /coord/x,y
if (clearwin_string@('callback_reason') .eq. 'DRAG_AND_DROP') then
  print*, 'Handle of moved icon ',clearwin_info@('dragged_icon')
  y = 400/2   !Force the vertical position to be constant in this case
end if
cb = 1
end function cb

Kenneth, thanks for the suggestions. Using an 'intermediate' form (like BMP or JPG) is a great suggestion.

I think what would serve me best is using the %gr and drawing the contents of the region directly into the graphics region itself. I have experimented, and can move the graphics region (like a control) wherever I like. By specifying full_mouse_input, I can 'grab' the graphics region and move it wherever I like within the containing window, similar to the Java code.

I am proceeding at a deliberate pace so that I (1) do not break any existing code, nor do I (2) box myself into a corner!

Bill

I am stumped, so thought I'd come back here and ask for help.

I've been playing around, creating one graphic object and then dragging it up/down. This worked fine if I did a clear screen and redrew the object , applying the offset when it was redrawn so that it was appropriately clipped.

So, I thought I'd try something different because redrawing causes the window to flicker. I was trying to treat a %gr like a window, moving it to the desired position by dragging it up/down, but I'm getting the strangest result.

The way the code is supposed to work: You'd click in the %gr object, then with the mouse button down, drag it up or down. Left/right should have no effect. What I'm seeing is that the %gr is moving down and right, never up.

In the callback for the %gr, note that the case ('MOUSE_MOVE') just gets the %gr location, and moves to that same spot. I took out the actual moving the window part just to simplify the problem. Yet, what it does is what I've described.

Here's the link on DROPBOX. I've packaged the project up in a ZIP file. https://www.dropbox.com/s/bmrc7gnp188u24f/FPStackFault.zip?dl=0