Can you use a %pm on a %tx window?

I'm trying to allow the user to right-click to start a pop-up menu. The key is the %tx coordinates of the right-click are important for the right-click. If I allow the standard processing of the pop-up menu, I can't get the %tx coordinates.

If I disable pop-up menu (NO_POPUP_MENU), but still define the %pm for the window, and handle the right click myself by using DISPLAY_POPUP_MENU@() when the right click is processed, I can get the %tx coordinates, the mouse coordinates, but not the pop-up item selected CLEARWIN_STRING@('CURRENT_MENU_ITEM'). The callback function for the %pm in this case never gets called.

Am I asking too much? Or, is there a different way to get the information needed?

Bill,

Some years ago, I couldn't get pop-up menus to work in a %gr region. I fought the system and eventually gave up. I was able to create my own pop ups inside the callback function with

         IA=WINIO@('%ww[no_maxminbox,volatile]&')
         IA=WINIO@('%ww[casts_shadow]&')
         IA=WINIO@('%ww[no_frame]&')
         IA=WINIO@('%ww[no_caption]&')
         IA=WINIO@('%sy[3d_thin,thin_border,toolwindow]&')
         IA=WINIO@('%bg[btnface]&')
         IA=WINIO@('%sp&', JXP, JYP)

followed by font setting etc, and making the lines in the pop up from %tt as in: (just a selection). JXP and JYP were coordinates from the mouse click adjusted slightly and taking into account proximity to the edge of the %gr area the pop up was in.

       IA=WINIO@('%12tt[Zone colour]%nl&')
       IA=WINIO@('%12tt[Properties]%nl&')
       IA=WINIO@('%12tt[Help]%nl&')
       IA=WINIO@('%12tt[Deselect Zone]')

It doesn't have the look I wanted, but it works. If this form of pop up loses focus, it is volatile and disappears. The drop shadow effect isn't so good as with XP, but is OK. I have several such pop ups, and they can also contain data input boxes instead of %tt 'buttons'.

Then, several releases of FTN95 later, Paul got %pm working (I found out from the updates list), but by then I was hooked on the versatility of not just a pop-up menu but a whole pop up dialog.

Not a lot of help with your original request, but a good 'other way'.

Eddie

Eddie,

Thanks for the code snippet. I may have to use this. Yes, not the most elegant way, but definitely usable!

Again, appreciate the response.

Bill

SDBG uses %tx and has a popup menu in at least one window so it seems to be possible. If you can post a simple program that illustrates the context then I will take a look at it.

Bill,

To add to what I sent you, I also set the font for the pop up and have an underlined heading on the menu thus:

       CALL SET_FONT_FOR_POP
       WRITE (DUMMY,'(I2)') NREGION ! DUMMY is CHARACTER*(2)
       IA=WINIO@('%cnRock No. '//DUMMY//'%bx%dy&', 1.0D0, 0.5D0)

The font is OS-specific:

      SUBROUTINE SET_FONT_FOR_POP
      IMPLICIT DOUBLE PRECISION (A-H, O-Z)
      INCLUDE <WINDOWS.INS>
      CALL GET_OS_VER@ (ID_Platform, Major, Minor)
      IF (Major .LE. 5) THEN                ! i.e. XP or earlier
          FACTOR = 0.8D0
          IA=WINIO@('%fn[MS Sans Serif]%ts&',FACTOR)
      ELSE                                  ! i.e. Vista or later
          FACTOR = 0.9D0
          IA=WINIO@('%fn[Segoe UI]%ts&',FACTOR)
      ENDIF
      RETURN
      END

I suspect that my program won't get run on very old machines, so this is archaeology.

I have a series of these pop ups, which can contain not just %tt (which I chose because of its height) but %bb (which can contain an icon) or even clickable bitmaps such as GIFs. I also have some responding to a button click with a callback, and others that just drop through and use the WINIO@ return code.

If Paul resolves your problem, you will at least have a standard look, but if not, this is easy to implement.

Eddie

Paul, thanks. I'm still experimenting. I'll let you know what I find.

Eddie, thanks for the additional code fragments. I'd like to retain the same look/feel, and at the same time I have some other functionality that needs to be implemented, so your approach might work even better.

I like experimentation with FTN95 and Clearwin+. There is a wealth of additional functionality that exists underneath the published documentation as well, and I'm using some of it!

Bill

Here's a link to a Plato project for this. The driver invoked the %tx with four different sets of parameters.

In the test results text file are the four cases described as to the effects. By way of explanation, I want the user to move the mouse to a character position, right-click, and have a choice of options displayed that are dependent on the characteristics that are at that character position. So having the text array coordinates is important. As is knowing which option in the pop-up menu was selected.

This is a highly stripped version of the code.

https://www.dropbox.com/s/f3pxk4ftmidu775/ForumTesting.zip?dl=0

I have the beginnings of something that works for me but depends on %cm which is new and probably not yet released (but you could use %pm for now). Note the use of permit_another_callback@ which is probably critical.

    character*40 text_array(10) ! define a 10x10 text array
    character*40 text_attribute(10) ! define the attribute
    integer i,k,winio@ 
    integer,external:: keystroke,pm_handler
    text_array = ' '
    do i=1,10
       call char_fill@(text_attribute(i),char(0))
    end do
    k = winio@('%ww[no_maxbox,fixed_size,topmost]&') ! force the main window to never disappear
    k = winio@('%ca[USE_TABS,FULL_CHAR_INPUT,FULL_MOUSE_INPUT]&')
    k = winio@('%fn[Courier New]%ts&',1.4d0) ! hass to be a fixed pitch font
    k = winio@('%bg&',255)
    k = winio@('%tc&',11141120)
    k = winio@('%cm[Item 1,Item 2,Exit]&',pm_handler,pm_handler,'Exit')
	K = WINIO@('%*.*^tx[USE_TABS,FULL_CHAR_INPUT,FULL_MOUSE_INPUT]&',40,10,text_array,text_attribute,40,10,KEYSTROKE)
	k=winio@(' ') 
	end

	integer*4 function pm_handler()
    print*, '<OK>'
	pm_handler = 2
	end
    
	INTEGER*4 FUNCTION KEYSTROKE()
	use clrwin
    call permit_another_callback@()
	keystroke = 2
	END

It was the PERMIT_ANOTHER_CALLBACK@ that did the trick in my application!

Thanks very much, Paul!

Further investigation yields the following results. It makes coding a bit more interesting.

The PERMIT_ANOTHER_CALLBACK@ definitely allows the popup menu handler to get involved rather than not being called. The sequencing of the callbacks and responses is interesting. I am not referring to the code segment I published, but to my actual code.

The KEYSTROKE function gets called when the right button is released. It then calls a KEYSTROKE message processor. The KEYSTROKE message processor then calls the PERMIT_ANOTHER_CALLBACK@ followed by the DISPLAY_POPUP_MENU@ call. I then retrieved the CURRENT_MENU_ITEM and it is blank. This is because the popup menu has actually not yet been created or selected. My mistake, glad I left a trail of breadcrumbs!

After the KEYSTROKE function has completed, then the popup menu is created and the options are now available. The appropriate pm handler gets called at this time. That's all good.

While this does not cause a problem in my code, I found it an interesting and logical outcome of processing the original message (right click), then processing the simulated right click to invoke the popup menu (PERMIT_ANOTHER_CALLBACK@ and DISPLAY_POPUP_MENU@). I post this so anyone who is interested in using this facility has my results with which to compare.

Thanks for all, Paul!