P F C
RMB BLUES

While developing applications with PFC, here are some disturbing problems I have faced with the RMB menus. I have been able to find work-arounds for some of these problems, while solution to others still remains elusive. I am using PB 5.0.0 and PFC 5.0.0. Please do let me know if these problems have been fixed in subsequent releases.
 

Problem 1

If an instance of u_dw is placed on a response window, on right clicking the RMB menu opens ridiculously offset to the mouse pointer.
 

Cause

This happens because PFC tries to pop the menu at the Pointer location with reference to the Frame window. That's fine for sheets, but for Response windows, the Pointer location must be with reference to the response window itself.
 

WorkAround

Unfortunately RMB menus are not a service and the 'rbuttonup' event in pfc_u_dw needs to be overridden. The script at the pfc_u_dw level is copied in u_dw event and changes are made to this script to treat response windows differently. One option is to change the part where PFC goes searching for the ultimate parent window. However just to keep things simple, I choose to change only the part where the menu is actually popped. The changed script as follows -

//rbuttonup for u_dw
.
.
.
.....
// Send rbuttonup notification to row selection service
if IsValid (inv_rowselect) then
 inv_rowselect.event pfc_rbuttonup (xpos, ypos, row, dwo)
end if

// Popup menu
//*************Start  of changes by Jiggy *********************
Window w_parentwin
this.of_GetParentWindow (w_parentwin)
If w_parentwin.WindowType = Response! Then
 lm_dw.m_table.PopMenu (w_parentwin.PointerX() + 5, w_parentwin.PointerY() + 10)
Else
 lm_dw.m_table.PopMenu (lw_parent.PointerX() + 5, lw_parent.PointerY() + 10)
End If
//*******************End of changes by Jiggy *****************
 
 

Problem 2

If one turns off the u_dw RMB menu by setting ib_rmbmenu = FALSE, the default edit menu provided by Windows is also turned off. This very inconsistent behavior and can confuse the user. Got a solution for this anybody ?
 
 
 

Problem 3

This problem is actually related to what seems to be a bug in the PB ListView. PFC list view(u_lv) opens the same menu(m_view) on rbuttonup, irrespective of whether the user has clicked on a ListView item or in the 'White Space'. This is not standard Win95 behavior and one would really like to open a context menu(with options like Open, Edit, Properties etc.) when clicked on a ListView item. A couple of ways to achieve this are either to modify m_view in pfc_prermb_menu or pop a totally different menu. Either ways, the logic will revolve around the 'index' parameter of the rightclicked event and would look something like this -

 If index > 0 Then
  //Clicked on a item
  Pop context menu
 Else
  //Clicked in white space
  Pop Normal PFC menu
 End If

This logic would have worked fine, except that when you right click on a LV item, the rbuttonup is fired before rightclicked !! While when one right clicks in the 'White Space', first rightclicked is fired and then rbuttonup. You can verify this by using the debug service(of_SetDebug(TRUE)) to see which event is triggered first. Try it out on a plain Jane, non PFC list view.

If I have not been able to explain the problem to you, just try to implement this -

The PFC menu m_view should pop up only when the user right clicks on space in the list view outside any item. If the user right clicks on an item, no menu should be pop-Ed.
 

Workaround

Right now, I am managing by overriding rbuttonup and keeping the descendant script empty. The menu popping is done from rightclicked. I know this is not as per Win95 standards, but at least I can pop the correct menus and the users usually can't tell the difference. Here's what the code in rightclicked event looks like -

m_my_rmb m_pop

If index < 0 THEN
 call super::rbuttonup // Normal PFC menu
Else
 //Popup the properties and actions menu
 m_pop = CREATE m_my_rmb
 m_pop.of_SetParent(this)
 m_pop.m_cat_properties.PopMenu(gnv_app.of_getframe().PointerX(), gnv_app.of_getframe().PointerY())
End If
  1