Prevent VK_RBUTTON from beeing generated

[norbert doerre]

Please help!
I have a problem with a library DLL offering a toolbar object which freezes the
program when the right mouse button is clicked while the cursor is over the
tool bar. There is no update available for that library, and thus I have to repair.

'
'
Select Case CbMsg
Case %WM_TIMER
Do While CursorOverToolBar()

'From here, I have to prevent the right mouse button event
'to be generated at all, just as long as the cursor
'is hoovering one of the toolbars.
''GetAsyncKeyState' does not help here.

end Do
End Select
'
'

'-------------------------------------------------------------------------------------------------------
' FUNCTION CursorOverToolBar
'-------------------------------------------------------------------------------------------------------
Function CursorOverToolBar() As Long
Local pt As PointApi
Local hWnd As Long
Local txt As String
GetCursorPos pt
hWnd = WindowFromPoint(pt.x, pt.y)
If hWnd Then
txt = txt & "X: " & Str$(pt.x) & " " & "Y: " & Str$(pt.y) & $CrLf
wTitle = String$(256, 0)
GetWindowText hwnd, ByVal StrPtr(wTitle), 256 'Get window title
wTitle = Extract$(wTitle, Chr$(0))
If wTitle = "BarLeft" Or wTitle = "BarTop" Then
Function = %True '<------------------
End If
End If
End Function

[Kev Peel]

Subclass the toolbar and intercept and block WM_RBUTTONDOWN. There are plenty subclassing examples in the source code section of this forum.

[Michael Mattias]

Select Case CbMsg
   Case %WM_TIMER
         Do While CursorOverToolBar()

'From here, I have to prevent the right mouse button event
'to be generated at all, just as long as the cursor
'is hoovering one of the toolbars.

You might also consider not using a timer loop here, instead intercepting the WM_MOUSEMOVE notification and/or using TrackMouseEvent + WM_MOUSEHOVER.

MCM

[Michael Mattias]

>hWnd = WindowFromPoint(pt.x, pt.y)

You might need to use CHILDWindowFromPoint here.

[norbert doerre]

The toolbar is from Borland, I think C++ 5.1 or 5.5, and i remember having read that this problem occured first with XP. I'm just trying to find a way more simple than subclassing....
Hovever, it's class name isn't TOOLBAR but DIALOG. So have to investigate....

[Michael Mattias]

Not one, not two, but THREE answers for you:

The first correct answer is "Contact Borland."

The second correct answer is, "include all relevant info when posting." That any part of your code is directly relying on a third-party library is relevant.

The third correct answer , with third-party 'black boxes' anything you want to do vis-a-vis subclassing is going to be one gigantic crapshoot.

You want simpler? What happened when you tried my suggestions? Then again, had I known a third-party product was involved, I would have qualified those suggestions with the obvious disclaimer: "New Shooter, Coming Out!"

[Chris Boss]

Instead of subclassing a control, you can trap the WM_KEYDOWN message in the applications message loop.

Keyboard messages are not sent directly to a controls window procedure, but they are put in the applications message que. This means they go through the message loop first before being forwarded to the controls window procedure.

You can test for the WM_KEYDOWN and WM_KEYUP messages in the message loop. Test the window handle to see if it is the toolbar control.

You can compare the window handle in the message loop to the handle from the function GetDlgitem (requires parent dialog handle and controls ID).

You can also test the controls classname using the GetClassName API function to see if it is the toolbar control.

An easy way to find the controls class name is to download the WinSpy utility from the PB web site. This tool can read any window from any application and generate code for you. I use it regularly to simply test a window/control to see what class it is.

I doubt a borland control uses the name Dialog for a class name.

[Roger Garstang]

Depending on what Borland it was built with, I usually have problems doing any event trapping or watching controls, etc. Borland likes to use Non-standard controls that appear to be only drawn on panels and when you use something like WinSpector to view the window thare aren't even any controls on the form. Makes it very difficult to do much with it.

[norbert doerre]

<Depending on what Borland it was built with...>
The Toolbar is definitely built with Borland c++ 5.1, and Roger, what You write is just what I experienced with a lot of Borland C++ built applications. My one has grown over the last 20 years to more than 960.000 lines of code. So, Michael, the coherence of all this is very hard to explain, starting with registered messaging and ending with one single bug inside a control depending from the OS. When I tell that standard messaging is sometimes not usable then this is simply the truth, and I cannot explain everytime I have a question in the forum from scratch what I'm currently working on. Its nearly always the same. On the other hand I can understand that people taking part here should get sufficient information. So I'm in a dilemma.
'MouseMove' over the toolbar window is represented by uMsg code 275. I'm able to get all info about the tool bar control, but the only hard thing is to prevent the right mouse button from beeing pressed while the cursor hoovers the blank part of the control. I think I'll do it with a programmed magnetic coil and a plastic log under the mouse button. ;-)
It would be no problem for me to change the control code in binary mode, but I'm not shure if this would run with all previous MS Os. So, what is more time consuming, installing all the OS and testing a patched control or using a (perhaps simple) software solution? I'd prefer the latter one. I do not need a code solution. Mostly a tip is sufficient, because You cannot have all in mind.
Rewriting the dilalogs is simply impossible, I would have to rewrite about 40% of all. On the other hand, besides this really small bug the program is running very fine and bug free. So why disturb it?

[Michael Mattias]

'MouseMove' over the toolbar window is represented by uMsg code 275

Oh, no, not these custom notification messages again!

Please include me out.

> On the other hand, besides this really small bug the program is running very fine and bug free. So why disturb it?

If that's true, why did you post your problem here?

If you've set out to confuse me, you win. Two points for you.


MCM

[norbert doerre]

Chris, Your suggestion is fine, and I often worked with it.
When I'm programming hard to solve vector math problems or when I have to debug in detailed simulating mode, I often use VB6 because of it's very fine and comfortable debugger. Afterwards, I transfer the code to PB.
With VB6, I can in fact get all 'KeyPress' codes You mention, but it seems that PB cannot catch them all. I had not yet the time to find out why, because I needed it perhaps only once a year.
There shurely exists a difference.

[norbert doerre]

Michael, just to answer your kind question:
I posted the problem here because it consists of more than the one an only line You citate, and, by the way, I did not include You IN, so why should I include You OUT?

[Cliff Nichols]

VB6??? ok now you lost me (Just Kidding Norbert)

Truth is I still use VB for quick tests that I am "Under the Gun" on ideas that I can not answer in 5 seconds or less (but thank god for PB and the CORRECT way to do things that my inquiry is "Is it possible?"

I can in fact get all 'KeyPress' codes You mention, but it seems that PB cannot catch them all. I had not yet the time to find out why, because I needed it perhaps only once a year.
There shurely exists a difference.

Not quite...I recently found myself needing to VB6 my way out of a problem, and found myself wondering "Now just What was that command again????" since I think I am safely 99 (well 98%) pure PB these days.....with the exeception of the convenience of "MouseDown" (which I can basically recreate myself) that I have gone from VB to PB....and not looking back

On the rule of making something work on a M$...follow the rules you can't get burned....follow the rules of the compiler...you may get singed, but not burned (depends on the compiler's interpretation of the api called)...depend on anything written by anyone that is NOT you....roll the dice and hope anything below you did their job right...(Including M$)...but I guess thats an "Oxy-Moron" to start with

The only thing that always buggs me is once I figure out the problem, I wonder "Why the 4377" (turn your calculator upside-down) did they not say that in the first place????

[norbert doerre]

Cliff, it's hard for me to understand Your English, especially Your last sentence. I certainly admit that VB6 does not produce an executable code which could be acceptable for any of my work. I nearly always work on DLLs, so this matter has nothing to do with VB6. But VB6 has the capability - because of it's interpreting function - just to give me sometimes a tool to simultaneously step through heavy math code, giving me the ability to see the variable contents by hoovering and at the same time showing the graphical result step by step. This method is quite comfortable. When the result is acceptable, I transfer it to PB and include it into the already existing PB code.
And Cliff, while You are joking, I know well the story about "real programmers". But it is only the commercial result and the way and the time to it which is relevant. During 30 years of coding, I learnt to know some programming languages coming and going. For my kind of work, compilers with an interpreting built in debugging IDE were always the best choice for coding, but the best compiler is currently PB - as long as MS will support SDK programming...

[norbert doerre]

Having again a look inside this tread I have to aknowledge that nobody seemed to be able in the mean time to give a hint that even the strategy in the code snipped I sent leads to nothing!
It is not done giving standard answers on standard questions.
So here the solution of the problem for those who might need it:

'Inside the initialisation code:
'
'
'The Hook-Handle for BarTop is given with gBarTopWnd
OriginalBarTopProc = SetWindowLong(gBarTopWnd, %GWL_WNDPROC, CodePtr(BarTopWindowProc))
'
'
'-------------------------------------------------------------------------------------------------------
' Correcting the right click bug of the Borland ToolBar
'-------------------------------------------------------------------------------------------------------
Function BarTopWindowProc(ByVal hWnd As Long, ByVal uMsg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long
Local pt As PointApi
Select Case uMsg
Case %WM_RBUTTONDOWN
uMsg = 0
End Select
Function = CallWindowProc(OriginalBarTopProc, hWnd, uMsg, wParam, lParam)
End Function

Thank Your for Your kind assistence.