View Issue Details

IDProjectCategoryView StatusLast Update
0006391JEDI VCL00 JVCL Componentspublic2016-08-07 00:11
ReporterlightrockAssigned ToAHUser 
Status resolvedResolutionfixed 
Product Version3.47 
Target VersionFixed in VersionDaily / GIT 
Summary0006391: JvAviCapture - ALT key issue
DescriptionDelphi XE2 - I can consistently get the jvavicapture to crash/halt/hang a program simply by pressing the alt key. The camera does NOT have to be running or connected. Something about the windows proc, the fact that the component exists on the form at all. The compiled application, examples, run OUTSIDE of the debugging environment - MIGHT NOT - exhibit the issue. IT WILL in the debugger. Any application no matter how simple, form, button jvavicapture, no wiring up of anything just RUN - ALT key will hang it - for me, even run the .exe straight outside the debugger. Confused on how to try to fix it, tried a few things. Somehow the jvavicapture gets in front of everything.
TagsNo tags attached.



2015-03-21 20:30

reporter   ~0021152

Oh crap. It must be allergy season or something, today, the keypreview of the form is working right and I can block the ALT key from messing it up. Spooky. Maybe I have some crapware installed or something. Can anybody see the same exact thing ? Is it just me ? Anyway I think it was my fault, ... somehow.


2015-03-22 08:40

reporter   ~0021153



I changed this line to look like this

    if (Msg <> WM_NCHITTEST) and (Msg <> WM_UPDATEUISTATE) then
      PostMessage(TWinControl(SelfObj).Handle, Msg, wParam, lParam);

It is happier now that is also skips the WM_UPDATEUISTATE

- This was also affecting the Delphi XE2 IDE, the fact that this is simply even a design time component appearing on a form... heaven forbid touch the Alt key...

Windows messages are not my forte, I get "good" at such things only if I have to. This is not good ( yet ). Just is, seems to work.


2015-03-22 13:52

developer   ~0021154

Wouldn't it be better to only post the messages to the SelfObj control that it is interested in (WM_SIZE, WM_SIZING, WM_MOVE, WM_MOVING, WM_WINDOWPOSCHANGING, WM_WINDOWPOSCHANGED) instead of posting all except those that are problematic and must be found by trail&error for every new Windows version?


2015-03-22 15:55

reporter   ~0021155

@AHUser: I don't know if you are "right" but you are certainly not wrong.
         Works just as well and like you were saying might be smarter

    // try it this way
    // if ( Msg in [... WM_SIZING, ... ] )
    // generates "constant expression violates subrange bounds"
    // therefore:
    // ----------------------------------------------------------
    case Msg of
      PostMessage(TWinControl(SelfObj).Handle, Msg, wParam, lParam);


2015-09-14 11:12

administrator   ~0021184

Well, when I first wrote that component, I did something similar, but there are heaps of (undocumented) messages that get sent when sizing or moving a window.
As a result, I did not want to filter them out just in case they were needed.


2016-08-07 00:11

developer   ~0021361

Fixed in master branch.

By changing the control handle creation to not create a child capture window but to *be* the capture window, the whole PostMessage and MoveWindow code isn't necessary anymore.

Issue History

Date Modified Username Field Change
2015-03-18 06:26 lightrock New Issue
2015-03-21 20:30 lightrock Note Added: 0021152
2015-03-22 08:40 lightrock Note Added: 0021153
2015-03-22 13:52 AHUser Note Added: 0021154
2015-03-22 15:55 lightrock Note Added: 0021155
2015-09-14 11:12 obones Note Added: 0021184
2016-08-07 00:11 AHUser Note Added: 0021361
2016-08-07 00:11 AHUser Status new => resolved
2016-08-07 00:11 AHUser Fixed in Version => Daily / GIT
2016-08-07 00:11 AHUser Resolution open => fixed
2016-08-07 00:11 AHUser Assigned To => AHUser