View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006391 | JEDI VCL | 00 JVCL Components | public | 2015-03-18 06:26 | 2016-08-07 00:11 |
| Reporter | lightrock | Assigned To | AHUser | ||
| Priority | normal | Severity | crash | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.47 | ||||
| Target Version | Fixed in Version | Daily / GIT | |||
| Summary | 0006391: JvAviCapture - ALT key issue | ||||
| Description | Delphi 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. | ||||
| Tags | No tags attached. | ||||
|
|
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. |
|
|
jvavicapture.pas customwndproc 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. |
|
|
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? |
|
|
@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 WM_SIZE, WM_SIZING, WM_MOVE, WM_MOVING, WM_WINDOWPOSCHANGING, WM_WINDOWPOSCHANGED: PostMessage(TWinControl(SelfObj).Handle, Msg, wParam, lParam); end; |
|
|
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. |
|
|
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. |
| 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 |
