Mouseover responsiveness for %tb and %ib

Is it possible to add mouseover sensitivity to %ib and %tb? It would be useful to be able to detect mouseover events and react to them. The specific reason is to permit fly-out secondary (and therefore somewhat volatile) toolbars to appear on mouseover, without requiring the parent toolbar button to be pressed.

%ib already displays some mouseover sensitivity, particularly when the [coloured] or [flat] attributes are used. It seems to me that it is necessary to detect both 'mouseover commenced' and 'mouseover finished' events, and these can be reported by the 'state_control' integer with values unused at present. So as not to break existing code, mouseover sensitivity would need to be switchable with a clearwin modifier such as ` (grave) - and not ^ (carat) for compatability with %tb.

%tb on the other hand has no mouseover sensitivity at present. It seems to me that so as not to break existing code, mouseover sensitivity would again need to be switchable with a clearwin modifier such as ` (grave). The mechanism of reporting mouseover events in this case would need to be via callback_reason, and a 5th bitmap (or a 4th, if greyed-out is not used) would be required.

Ordinary text buttons 'perk up' on mouseover (with 1 24 default.manifest), but Windows norms never require this to be detectable by the program. Plenty of programs, and web pages, respond in some way to mouseover events, and it would be a useful addition to Clearwin.

Eddie

I will see what can be done. Remind me in a couple of weeks if you don't see any response here.

Eddie

I have had a go at %ib with the result that the following code works OK apart from the alignment of the popup menu that flies out when you hover over the button. Naturally you cannot test it at the moment but you can get an idea of how things are progressing. If this is about right then I will fix the alignment issue.

At the moment I am only thinking of %ib and using a callback response.

  winapp 
  integer winio@,i,cb1,hwnd,cb
  external cb1,cb 
  common hwnd
  character*80 menu
  menu = '[]'
  i=winio@('%ww%ca[Image bar]%sy[3d]&') 
  i=winio@('%hw&',hwnd)
  i=winio@('%bd&',0.0D0,0.0D0,0.5D0,1.0D0)  
  i=winio@('%mn[File[Exit]]&','EXIT') 
  i=winio@('%`pm&',menu,cb) 
  i=winio@('%ib[flat]&','cut/Cut',4,cb1) 
  i=winio@('%ff%gr[black,full_mouse_input]',300,200) 
  end 

  integer function cb()
  include <windows.ins>
  character*16 menuitem
  menuitem=clearwin_string@('CURRENT_MENU_ITEM')
  cb = 2
  if(menuitem == 'Quit') cb = 0
  end
  
  integer function cb1()
  include <windows.ins>
  integer hwnd
  common hwnd
  character*80 reason,menu
  logical entered
  save entered
  data entered/.FALSE./
  menu = '[Quit]'
  reason = clearwin_string@('callback_reason')
  if(reason == 'MOUSE_ENTER' .AND. .NOT. entered)then
    call replace_enhanced_popup_menu@(hwnd, menu)
    call align_popup_menu@(0)
    call display_popup_menu@()
    entered = .TRUE.
  endif
  if(reason == 'MOUSE_LEAVE') entered = .FALSE.
  cb1 = 2
  end
  
  resources 
  cut BITMAP cut.bmp 

Paul,

In my original note, I used the term mouseover sensitivity - of course there is mouseover sensitivity, even without [flat] or [coloured] , it reflects in the help string popups. You rightly detected that I meant to be able to detect, and respond programmatically to, mouseover.

If in %ib this state is detected in a callback function through a clearwin reason, then it has the potential to break existing code that does not query this reason (why should it?), which worries me on behalf of other users. Also, %ib communicates with the outside world through the mechanism of the state control integer, and to have to examine a callback reason as well seems to me to rather overcomplicate things, and to go against the philosophy of how the %ib works. This is a bit like 'looking a gift horse in the mouth', for which I apologise, but %ib is already rather different to the way other format codes are programmed.

I'm aware that the FTN95 documentation describes %ib as an improvement and replacement for %tb. However, %tb allows the programmer to do things that are impossible with %ib. For example, the disabled state image for an %ib button is rendered in 2 shades of grey (with a third simulated by dithering). Then, you have to struggle with the base coloured image so that the disabled state icon is not simply a blob. With %tb you can make the disabled state icon use all the greys, have a better 3D shape - and, because the up and down icons are fully drawn, you can introduce simple animation (for example, a light on a printer icon winks on-off, paper advances, etc). Then, the selected icon is more versatile than just appearing depressed.

Hence I can't help but think it would be a pity if you ignore %tb (perhaps believing that %ib replaces it).

Eddie

If I add additional states to the state variable will this not also have the potential of breaking existing code. Either way I can provide an option to enable mouse-over sensitivity.

I am looking at %ib initially because it is the more popular control and because it already has mouse sensitivity. The work is non-trivial and therefore time consuming and expensive. I will aim to have a look at %tb later to see what can be done.

Apart from these points, is this the kind of functionality you are asking for?

Paul,

From browsing the code you posted, I believe it is what I was suggesting.

The specific need which gave rise to my original suggestion is twofold for %tb (but simpler for %ib):

1. To be able to make the control respond as the Windows style guide suggests with a different appearance on mouseover to show that the control is clickable, and
2. In the case of both %ib and %tb, to allow the programmer to respond to mouseover.

The particular response to mouseover that I envisage is to have fly-out or drop down sub-toolbars that appear on mouseover and disappear if focus is lost. I can program this is the parent control is actually clicked (and this is highly effective), but for obvious reasons not on mouseover. This type of functionality is used in the graphics application CorelDRAW that I use a lot, and I am impressed by it, as it allows the basic program interface to appear relatively uncluttered initially (although CorelDRAW has many more icons than I would consider in my programs*), and yet the functions are only one click away. If the parent icon is clicked, they are* two* clicks away, and the user may even remain unaware that the options exist via a toolbar. Why I believe that the state variable is the way to go with %ib (and I say this deferentially, because you understand the system better than I do) is that the values which are not used to date are declared in FTN95.chm to be reserved, and this means that existing code can not test for other than the described values (except generically, as in 'not 1,2,3 or 4') and so other values ought not to break existing code. If a value other than 1 to 4 inclusive is returned, existing code ought to do nothing. I did once test what happened with other values, and one of them I remember gave interesting results, although what they were I forget! I did mention it in a forum post. Additionally, if the programmer needs to specify in advance that mouseover sensitivity is to be enabled, then that also cannot break existing code. I did think very carefully about such implications before writing my original suggestion. Regarding %tb, I haven't mastered putting images in this forum, but I do have an example screen grab of the results of one of my efforts using %tb in Picasa at http://picasaweb.google.com/OldFortranMan/RecentlyUpdated#5337116929473889858. This shows some active and some disabled icons on the toolbar. I had huge problems in getting the icons to abut properly (it transpired that it was associated with the large fonts setting on a particular PC) and one of the images at the above website shows the toolbars in a 'fractured' state, and the other how I resolved the issue by sliding a %bm bitmap underneath the toolbars (there is a judicious use of %ap as well). This is all done in FTN95/Clearwin as I haven't a clue how else to do it. The icons all animate when pressed (can't show this in Picasa) and when selected they appear within the orange box as in Office 2003). Ideally, they ought to change their appearance with mouseover too (Office 2003 uses a yellow box rather than the orange box that indicates both 'down' and 'selected'). Being able to use 'mouseover flyout' toolbars would enable me to simplify this, or conversely to add functionality without further complication. To be frank, if starting again, I would use neither %tb nor %ib, but would program the toolbars from scratch with icons imported using IMPORT_IMAGE@ in a single %gr area. Based on some experimentation I have done, I have been able to program repositionable toolbars with full mouseover sensitivity and animation more complex than simply up-down (but the graphics area calback function is huge, even for my test program!). I reckon that the effort to change my main application is about 3 weeks of long days and nights. The reason I put the suggestion forward for mouseover sensitivity is that if I did what I know I can do, no-one else could have the benefit. Eddie

I have finished my development for %ib and the result is illustrated in the following code. Given the time and effort that has been needed for this relatively simple extension, I do not plan to do any work on %tb at the moment.

There is one down-side to the displayed result for the code below and it is that the button itself does not respond to the mouse hover as one would prefer. This is why I have used [coloured] with [flat]. This is because of timing issues and the way the existing code has been designed.

  winapp 
  integer winio@,i,cb1,cb
  external cb1,cb 
  i=winio@('%ww%ca[Image bar]%sy[3d]&') 
  i=winio@('%bd&',0.0D0,0.0D0,0.5D0,1.0D0)  
  i=winio@('%mn[File[Exit]]&','EXIT') 
  i=winio@('%`pm&','[]',cb) 
  i=winio@('%ib[flat,coloured,mouse_hover]&','cut/Cut',4,cb1) 
  i=winio@('%ff%gr[black]',300,200) 
  end 

  integer function cb()
  include <windows.ins>
  character*16 menuitem
  menuitem=clearwin_string@('CURRENT_MENU_ITEM')
  cb = 2
  if(menuitem == 'Quit') cb = 0
  end
  
  integer function cb1()
  include <windows.ins>
  C_EXTERNAL display_ib_menu@ '__display_ib_menu'(VAL,INSTRING)
  character*80 reason
  logical entered
  save entered
  data entered /.FALSE./
  reason = clearwin_string@('callback_reason')
  if(reason == 'MOUSE_ENTER' .AND. .NOT. entered)then
    call display_ib_menu@(0, '[Quit]')
    entered = .TRUE.
  endif
  if(reason == 'MOUSE_LEAVE') entered = .FALSE.
  cb1 = 2
  end
  
  resources 
  cut BITMAP cut.bmp 

Hi Paul,

This is a heroic effort in a short time.

There's a lesson in it for me - actually one I learnt several times already but keep forgetting - and that is that the original design of something is critical when it comes to modifying it or extending it, and that's true of programming as well as in the design of tangible objects. Sometimes, the neat, compact and elegant original solution is the one that's difficult to change.

Eddie

I notice with version 6.00 the 'hover' option is now in place.

Running old versions of our applications against the latest DLL causes the commands that would naturally get invoked when an icon is clicked now get invoked by simply hovering the mouse over the icon.

Is this what you would expect ?

No, this is a regression that has now been fixed in the salflibc.dll for the next release.