Standard Call Back Function 'COPY'

I have developed several finite element related applications that all create two windows each.

The main window in each application contains a graphical display of the FE model, with which users can interact and interrogate their models. The second window uses %cw to display the results of interrogations as text.

I wish to give users the capability to copy text from this window into other applications like word. However if I just have the standard call back function 'COPY' it is always greyed out when text has been highlighted using the mouse cursor. I then found out by trial and error that if I added the 'PASTE' call back, the 'COPY' is still initially greyed out but the 'PASTE' usually isn't. So I click on 'PASTE' and then usually 'COPY' is no longer greyed out and allows me to copy and paste text into other apps.

However, this method is rather hit and miss, sometimes working and sometimes not, also the text transferred into the clipboard buffer is very often truncated from what was highlighted in the %cw window. This has frustrated me for several years and any help would be most appreciated.

These extracts are taken from the most simple of my programs:-

Text window using %cw :-

  i=winio@('%ww %ca@ %sp &',PROG_NAME,0,0)
  i=winio@('%mi[ICON_1]&')
  i=winio@('%mn[&Edit[&Copy,&Paste]]&','COPY','PASTE')
  i=winio@('%pv%80.20cw[vscroll,hscroll]%bg[grey]%lw',6,iwrite6)

Graphics window :-

  i=winio@('%ca@&',PROG_NAME)
  i=winio@('%mi[ICON_1]&')
  i=winio@('%`9cu&',CURSOR_ARROW,CURSOR_IBEAM,CURSOR_WAIT,
 *CURSOR_CROSS,CURSOR_UPARROW,CURSOR_SIZE,CURSOR_ICON,
 *CURSOR_SIZEWE,CURSOR_SIZENS,K_TYPE)

  i=winio@('%ww[no_border]&')
  i=winio@('%pv%`^gr[black,user_resize,full_mouse_input]&',
 *IX_PC,IY_PC,IHNDL,CALLBACK)
  i=winio@('%lw',ictrl)

:laugh:

I may be necessary for you to post the full program to be able to understand what is wrong.

%cw is read-only so, in theory, PASTE should have no effect with %cw. The other thing that you need to know is that COPY works on the control that currently has the focus. This means that you must access COPY by a menu item (preferably a popup menu on the %cw control) or an accelerator key. A button will not work because, when you click on it, the button will have the focus.

Paul

Thanks for getting back.

I tried your suggestion of using a popup menu, but unfortunately I am still getting the same bizarre behaivour. I changed the %cw window to the following:-

  i=winio@('%ww %ca[Roshaz] %sp &',0,0)
  i=winio@('%mi[AA_ICON_1]&')
  i=winio@('%pm[&Copy,&Paste]&','COPY','PASTE')
  i=winio@('%cc&',CLOSE_WINDOW_TRAP)
  i=winio@('%pv%60.20cw[vscroll,hscroll]%bg[grey]%lw',6,iwrite6)

If I have just the 'COPY' callback on it's own then it is always greyed out. As before I highlight text in the %cw window using the mouse cursor, I then right click on the mouse button and the popup menu behaves in exactly the same way as the menu using %mn did !

The help on %cw in both the manual and as installed state:-

'The standard call-back functions CUT, COPY and PASTE can be used in this context. %cw is normally used for output and in particular for debugging.'

Unfortunately the full program has 210217 lines of source code, so I didn't think that you would like me to post it !

I shall probably construct a noddy program instead.

Paul

Here is source code of a simple image viewing program, with a graphics window and a text window which just writes the image file names. This program exhibits exactly the same problems in copying text from the text window into the windows clipboard as with my larger programs.

  program Image_Viewer

  include <clearwin.ins>,nolist

  EXTERNAL File_Open,CLOSE_WINDOW_TRAP

  COMMON /HANDLES/iwrite6,ictrl

  iwrite6=0

  i=winio@('%ww %ca[Image Viewer] %sp &',0,0)
  i=winio@('%pm[&Copy,&Paste]&','COPY','PASTE')
  i=winio@('%cc&',CLOSE_WINDOW_TRAP)
  i=winio@('%pv%60.20cw[vscroll,hscroll]%bg[grey]%lw',6,iwrite6)

  Write(6,*)'Simple Image Viewer'
  Write(6,'(1X,19(''~''),/)')

  ictrl=0

  i=winio@('%ww %ca[Image Viewer]&')
  i=winio@('%mn[&File,&Exit]&',File_Open,'EXIT')
  i=winio@('%gr[rgb_colours,black]&',640,480)
  i=winio@('%cc&',CLOSE_WINDOW_TRAP)
  i=winio@('%lw',ictrl)

  end

  INTEGER FUNCTION File_Open()

  use clrwin

  CHARACTER*132 FILE,PATH
  CHARACTER*17  NAME(4),SPEC(4)
  CHARACTER*3   EXT

  NAME(1)='All image types  '
  NAME(2)='Bitmap picture   '
  NAME(3)='PCX paintbrush   '
  NAME(4)='JPEG image       '

  SPEC(1)='*.bmp;*.pcx;*.jpg'
  SPEC(2)='*.bmp            '
  SPEC(3)='*.pcx            '
  SPEC(4)='*.jpg            '

  FILE=' '
  PATH=' '

  CALL GET_FILTERED_FILE@('Picture file',FILE,PATH,NAME,SPEC,4,1)

  EXT='   '
  L=LENG(FILE)

    IF (L.GT.4) THEN
      write(6,'(/,''Image displayed : '',A,/)')file(1:l)

      EXT=FILE(L-2:L)

        IF (EXT.EQ.'BMP'.OR.EXT.EQ.'bmp') THEN
          CALL DISPLAY_IMAGE_FILE('B',FILE,L)
        ELSE IF (EXT.EQ.'PCX'.OR.EXT.EQ.'pcx') THEN
          CALL DISPLAY_IMAGE_FILE('P',FILE,L)
        ELSE IF (EXT.EQ.'JPG'.OR.EXT.EQ.'jpg') THEN
          CALL DISPLAY_IMAGE_FILE('J',FILE,L)
        END IF

    END IF

  File_Open=2

  END

  SUBROUTINE DISPLAY_IMAGE_FILE(CP,FILE,L)

  use clrwin

  CHARACTER*(*) FILE
  CHARACTER*1   CP

    IF (CP.EQ.'B') THEN
      IDIB=IMPORT_BMP@(FILE(1:L),IERROR)
    ELSE IF (CP.EQ.'P') THEN
      IDIB=IMPORT_PCX@(FILE(1:L),IERROR)
    ELSE IF (CP.EQ.'J') THEN
      CALL DRAW_FILLED_RECTANGLE@(0,0,640,480,RGB@(0,0,0))

      IDIB=IMPORT_IMAGE@('{'//FILE(1:L)//'}',0,0)

      RETURN
    END IF

    IF (IERROR.NE.0) THEN
      WRITE(6,*)'ERROR opening picture file =',IERROR

      RETURN
    END IF

  CALL DRAW_FILLED_RECTANGLE@(0,0,640,480,RGB@(0,0,0))

  IERROR=DIB_PAINT@(0,0,IDIB,0,1)

  RETURN
  END

  INTEGER FUNCTION CLOSE_WINDOW_TRAP()

  use clrwin

  COMMON /HANDLES/iwrite6,ictrl

    IF (ICTRL.NE.0) THEN
      ICTRL=0
      call window_update@(ICTRL)
    END IF

    IF (IWRITE6.NE.0) THEN
      IWRITE6=0
      call window_update@(IWRITE6)
    END IF

  CLOSE_WINDOW_TRAP=0

  END

Many thanks in advance.

John

John

The manual is incorrect and the help file has already been changed for the next release. %cw is read-only and both CUT and PASTE should have no effect.

I do not know the reason for this odd behaviour. In your sample program, the problem can be fixed by creating the two windows in the reverse order. Otherwise you need a previous COPY (by an accelerator key for example) before the COPY menu item becomes enabled.

If you create the %cw window last, you may end up with the wrong window on top. This can be fixed by, for example, a %sc callback that calls the Windows API function BringWindowToTop. That is, get the Windows handle for the graphics window and use it in BringWindowToTop in a %sc callback attached to the %cw window.

Paul

I tried your suggestion of reversing the order of window creation, initially it appeared to work, but with continued testing I found that 'COPY' was still occasionally greyed out and when highlighting several lines of text the selection was always truncated when pasted into an editor. I then realised that the sample program had become very 'flakey' , as it crashed out on me with the following error message when I clicked on 'COPY' :-

Runtime error from program:c:\roshaz\develope\image_viewer.exe Access Violation The instruction at address 1c033acb attempted to read from location 00000018

1c0338d9 __get_selected_clearwin_text [+01f2] 1c06adad edit_copy(void)#70 [+0104] 1c047749 call_function(<ptr>(func()─returning─int),<ptr>char,enum─logical,enum─logical)# [+010d] 1c031d43 __yield_program_control [+0013] 1c050122 __temporary_yield [+0011] 1c085382 exit_cleanup(void)#70 [+00dc] 1c02ca2d do_atexits(void) [+0018] 1c02cb2b __fortranexit [+000c]

eax=00000018 ebx=04196acc ecx=04197265 edx=0417543c esi=00000018 edi=046972b4 ebp=0360f2f4 esp=0360f2b4 IOPL=3 ds=0023 es=0023 fs=003b gs=0000 cs=001b ss=0023 flgs=00010206 [NC EP NZ SN DN NV]

1c033acb rep 1c033acc movsb 1c033acd mov edi,[ebp-0x24]

Bizarrely I discovered that it was only safe to highlight text from the top down using the mouse cursor, highlighting text from the bottom up consistently crashes with the above error message. I tried the debugger, which gave no clues and an unhelpful message 'Access Violation' !

I don't think that I'm going to win with this one ! 😦(

John,

Please forgive me for butting in when a quick perusal of your code shows that you are far more knowledgeable about Clearwin than I. Surely you should be using an %eb, which has far more sophisticated Cut/Copy/Paste than a %cw window, which as Paul says is intended for output only. The %eb could have (for instance) Paste disabled. The trouble with it is that it would clearly need a much greater effort in coding the Fortran “behind the scenes”. However, you would be using a subset of the facilities of a powerful control, not overstretching the capabilities of a simple one.

Although I went on a day Clearwin course at Salford when it first came out, I hadn’t done much with it. Indeed, I struggled to do even the simplest graphics until I realised that one needed a %gr and not a %dw (which was used in the only example code I could find). I was used to the DBOS graphics, and the %dw was supposed to support something of those routines, and I had hellish problems until I realised I was using the wrong tool. Sure, you can drive in screws with a hammer, and it is quite effective – but the hammer is hopeless for getting them out again! May I respectfully suggest that your use of %cw is a case in point – like my use of %dw – one of using the wrong tool? That the documentation says that it (%cw) should support windows editing is another matter … it also gives the impression that you can use the DOS-extended Fortran graphics in a Clearwin %dw!

I’ve had an interest in finite element methods, and can see that in your 200k plus lines of code you must have encountered – and solved – a problem that has been bugging me for some time, which is the problem of providing a facility for the user to enter – and then edit to correct – lists of such things as coordinates for nodes. I can’t get it out of my mind that the most efficient way of getting such lists prepared is to put them in (say) Excel, and export them as a text file – and that even if I devoted the rest of my life to the problem, I couldn’t put as many man years of development into the problem as have gone into the average spreadsheet program. What do you do?

I'm currently wrestling with a far simpler problem than yours ... see the previous-but-one thread.

Regards

Eddie B.

Hi Eddie

I don't mind you butting in at all. I had considered %eb , which in the sample program would be the best tool to use, but the sample program is exactly that , just a small piece of code to demonstrate the problem I have with my real applications. In the context of the real full size applications %eb is impractical. The softwares that I have written are developements of programs dating back well over twenty years where the first graphical programs used Tektronix monochrome storage scope displays. These terminals could display text as well as graphics via escape sequences, and was hence the beginings of two streams of output, i.e text and graphics. Things improved considerably with the Tektronix 4100 series which had colour graphics for the first time and a truely separate text display as well. The computers in vogue at the time were the Digital VAX machines running under the OS VMS (how the mighty have fallen !). From there the codes migrated simultaneously to PC's using Salford FTN77 and DBOS and also to HP unix workstations using Xwindows. Porting the code from DBOS to MS windows was relatively straight forward as %gr accepted all the old DBOS graphics calls, although the codes were still command line driven using a mouse pickable menu structure unaltered from Tektronix days. The task of changing to a true windows interface took a fair bit longer to do! The command line is still there, but now hidden from the user, as it is very useful in logging commands, creating batch command script files and so on.

Going back to the question of using %cw to display text, it is not uncommon to have models of well over 2 million nodes which my software compiled in FTN95 is quite happy to handle and display. Vast amounts of data can, whether intentionally or not, be written to the text window from a polygon pick on the graphics window, interrogating for nodal stresses or what ever is requested. All serious FE based pre and post processing software uses an approach very much like mine (Patran and Femap have a text area beneath the graphics area within the same window, whilst Cadfix gives you the added choice of having a separate window for the text). The difference being that the user can easily copy any selected text to other applications with these other FE based softwares. I would like to have the same capability. True, I could create a new window for each interrogation of the model and place an %eb box in it. But that would be a very daunting task, since all I currently do is use a standard fortran 'write(6,*)' statement which %cw very conveniently captures and displays the text. Creating new dialog windows to display text using %eb could very easily clutter up the screen if the user failed to close the window, if you re-used the same window you lose the text results from previous interrogations, whilst with %cw you only have to scroll up the window to compare results (e.g nodal results against element results).

Your talk of using spreadsheets or even text editors (although still done in certain quarters) for creating nodal coordinates, harks back to a long gone time ! Very few people would even dream of doing that these days (especially with 2+ million nodes !!). Everyone made mistakes building models that way, I did 25 years ago and you only found your mistake (the next day) from scanning through the line printer readout of results, as graphics output (pre-Tektronix) was using asterisks on 132 column lines from the line printer !!!

Meshers are now fully automated, importing CAD data, checking and cleaning if necessary, then for complex 3D geometry filling the volumes with tetrahedral elements and refining the mesh densities in user selected regions. Manual creation/editing of nodes although still possible should never really be necessary.

Anyway, thanks for your input, I do find these forums useful as you always find a trick or way of doing something that previously eluded you, for example the time limited splash screen from your thread is a little gem ! (I would have appreciated some help like that when I converted from GDI graphics using %gr to OpenGL graphics using %og)

best regards John H. 😄

John,

Aha - there you go. I'm quite happy with 50 or 60 elements. Even that would have seriously challeged the capabilities of the Elliot 4120 and the IBM 1130 I cut my teeth on. I also use curvilinear isoparametric elements with Gaussian integration as a tool to integrate (non-finite element things) over arbitrarily-shaped areas, and have had good results with as few as two 8-node elements in doing that! I am only concerned with lists of around 20 x,y,z coordinates ... a different world to yours. I'm impressed that a PC can handle 2 million of anything - my first Apricot PC would barely run WordStar. Nevertheless, it changed my life.

I was suggesting that you managed the %eb edit box as a window onto a much larger text file created by your standard fortran writes and did handle the scrolling forwards and backwards yourself (in Fortran) when you go out of the currently displayed region, not to create a new window each time with an %eb in it. I can see that a %cw is much more convenient because it 'looks after its own scrolling'. Frustrating, isn't it, when all that is needed is for %cw to do what it says in the documentation. It doesn't seem to me to be too difficult to manage the scrolling. I suppose that I would maintain a large array of CHARACTER*80 (or *132, or whatever), and each WRITE(6,.. would go to the next one. You would only need a few pointers to keep track of what needed to be displayed currently, and where the start and end points for selection were, and where the position was to write the next record.

(for example, instead of WRITE(6, ... you might use WRITE (OUTPUT6(NPTR), ... where OUTPUT6 was a big array of CHARACTER items, and NPTR was the pointer to the next free one).

I would expect that you would need to handle COPY yourself, going through the Windows API to park things in the Clipboard. It might be easier if you limited the selection to complete lines. Within 200k lines of code, a couple of hundred more might be a worthwhile investment! On reflection, you probably don't even need an %eb ... just a window to display characters in. It could even be a graphics window.

I have a feeling that %cw is never going to be upgraded to meet the documentation.

I had a brief experience of the Tektronix terminals, but they were out of my price range. I've been using pen plotters for my graphics since 1969 - altho' they now seem to be a thing of the past. The nice thing about them is that their commands could be hard coded in Fortran, and weren't system dependent. I also deeply regret the passing of the ESCape code!

As you say, the time-limited splash is great - I've tried it, and the 2.0D0 delay is really too fast. 6 or 7 is better. The problem with it is the size of the bitmap. My EXEs are under 100k ... and the splash bitmap can treble that! Also, I have a feeling that one probably wants two or three variants, of different sizes, to cope with the target resolution of the screen on which the thing is displayed, although thankfully, most people seem to be able to manage at least XGA these days. It probably also needs to be of a low number of colours, also to make the file smaller.

And I still can't get %rf[initially_blank] boxes to live comfortably with radio buttons ...

Eddie B.

This behaviour reminds me of a bug that I fixed fairly recently. The fix will be in the next release which hopefully will be available next week.

Eddie, Paul

Thanks for your comments. I'm mulling over what to do, as Eddie's suggestions are quite reasonable and possible, but I think that any user would really expect to be able to highlight and imediately copy any text straight to the clipboard, as is normal behaivour in any windows application. Any deviation from the 'windows standard' is to be avoided, as programs that do are considered quirky, awkward and difficult to use.

Eddie, in the splash window I made, I used a small bitmap and placed rather large italic text to the side of it, this had much less impact on program size than a single large bitmap, but was still very effective.

regards John

JPEG files are much smaller than bitmap files. You can use %im with a jpeg file instead of a bitmap. The resource is an IMAGE rather than a BITMAP.

You can use Microsoft Paint to open a bitmap file and output a JPEG file.

That's useful. I let my enthusiasm get the better of me an immediately went and drew a whacking great bitmap in 24-bit colour with complex blends - and in response, got a huge bitmap! Plato does the opening splash well, with few colours and a memorable image.

Eddie