Announcement

Collapse
No announcement yet.

Prevent VK_RBUTTON from beeing generated

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Prevent VK_RBUTTON from beeing generated

    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
    Norbert Doerre

  • #2
    Subclass the toolbar and intercept and block WM_RBUTTONDOWN. There are plenty subclassing examples in the source code section of this forum.
    kgpsoftware.com | Slam DBMS | PrpT Control | Other Downloads | Contact Me

    Comment


    • #3
      Code:
      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
      Tal Systems (retired)
      Port Washington WI USA
      [email protected]
      http://www.talsystems.com

      Comment


      • #4
        >hWnd = WindowFromPoint(pt.x, pt.y)

        You might need to use CHILDWindowFromPoint here.
        Michael Mattias
        Tal Systems (retired)
        Port Washington WI USA
        [email protected]
        http://www.talsystems.com

        Comment


        • #5
          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....
          Norbert Doerre

          Comment


          • #6
            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!"
            Michael Mattias
            Tal Systems (retired)
            Port Washington WI USA
            [email protected]
            http://www.talsystems.com

            Comment


            • #7
              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.
              Chris Boss
              Computer Workshop
              Developer of "EZGUI"
              http://cwsof.com
              http://twitter.com/EZGUIProGuy

              Comment


              • #8
                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.
                sigpic
                Mobile Solutions
                Sys Analyst and Development

                Comment


                • #9
                  <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?
                  Last edited by norbert doerre; 21 Apr 2008, 05:48 PM.
                  Norbert Doerre

                  Comment


                  • #10
                    '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
                    Michael Mattias
                    Tal Systems (retired)
                    Port Washington WI USA
                    [email protected]
                    http://www.talsystems.com

                    Comment


                    • #11
                      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.
                      Last edited by norbert doerre; 21 Apr 2008, 05:45 PM.
                      Norbert Doerre

                      Comment


                      • #12
                        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?
                        Norbert Doerre

                        Comment


                        • #13
                          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????
                          Engineer's Motto: If it aint broke take it apart and fix it

                          "If at 1st you don't succeed... call it version 1.0"

                          "Half of Programming is coding"....."The other 90% is DEBUGGING"

                          "Document my code????" .... "WHYYY??? do you think they call it CODE? "

                          Comment


                          • #14
                            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

                            Comment


                            • #15
                              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.
                              Norbert Doerre

                              Comment

                              Working...
                              X