|
2004-06-08 07:53
|
Captura.gif (5,182 bytes) |
|
|
I have seen that who makes the process to change to the day and the month it is the OnChange procedure of the JvDatePickerEdit unit, but in concrete the line "SelText := Format('%.*d', [lActFig.Length, AValue]);" of the SetActiveFigVal procedure that is within the OnChange |
|
|
Hmm, I cannot reproduce that here. As you can see in the Change method code, SetActiveFigValue is explicitly *not* called during deletion operations. Please also note that currently all descendants of TJvCheckedMaskEdit (this includes TJvDatePickerEdit and TJvDBDatePickerEdit) are broken due to changes made to the ancestry of those components. One symptom of this is the extra button control that is also visible in your screenshot. Watch 0001811 for details on progress made regarding this issue. The change that caused the breakage was made on 2004-05-16, so I wouldn't recommend using any snapshots as of that date until this issue has been fixed. Personally I'm using a snapshot from 2004-04-20 for our production. |
|
|
i put a video with error reproduce |
|
2004-06-09 04:33
|
video.avi (79,872 bytes) |
|
|
Weird. As I said before, this doesn't happen here and judging by the code I have no sensible idea how this could happen at all. The whole FDeleting stuff was put in there specifically to prevent exactly this behaviour. Hypothetically, the only way I could see this happening with the current code was if for some reason your backspace key returned a virtual key code other than VK_BACK... (take a look at the KeyDown method to see what I'm talking about) Then again, maybe it's all just another issue caused by the inadvertedly changed ancestry... could you maybe retry with a set of sources from between 2004-04-20 and 2004-05-15? |
|
|
When key VK_BACK is called to the OnChange procedure when tightening the variable "Text" that ahi within her just contains the correct value of the date ("01/0 / ") before calling to the procedure SetActiveFigVal(const AValue: Word); after leaving the variable "Text" it contains the chain ("01/01/ "), the components that I am using are JVCL3-2004-06-08.zip and its KeyDown component is: procedure TJvCustomDatePickerEdit.KeyDown(var AKey: Word; AShift: TShiftState); begin if Text = NoDateText then begin Text := ''; RestoreMask; end; if AllowNoDate and (Shortcut(AKey, AShift) = NoDateShortcut) then begin Date := 0; end else case AKey of VK_ESCAPE: begin CloseUp; Reset; end; VK_DOWN: if AShift = [ssAlt] then DropDown; VK_BACK, VK_CLEAR, VK_DELETE, VK_EREOF, VK_OEM_CLEAR: FDeleting := True; end; inherited KeyDown(AKey, AShift); end; |
|
|
"When key VK_BACK is called to the OnChange procedure when tightening the variable "Text" that ahi within her just contains the correct value of the date ("01/0 / ") before calling to the procedure SetActiveFigVal" The point is that SetActiveFigVal should not get called at all when carrying out any kind of deleting operation. See in the Change method where it says: if (not FDeleting) and EnableValidation then begin ... The FDeleting should have been set to True in the KeyDown handler and thus the following bit of code (which indirectly calls SetActiveFigValue via EnforceRange) should really never get executed in that context at all... the only way this code could get called is if FDeleting was False... so far I have no idea why this seems to happen in your case... As I said before, it'd be interesting to see whether you could reproduce this problem with the code from before 2004-05-15... |
|
|
I have seen that when goes to onchange the FDeleting variable this to True with which it does not give the failure, but later the variable one takes the False value and it becomes to execute the OnChange procedure without before to have called to the KeyDown procedure with which it enters the OnChange procedure with the FDeleting variable to False executing code of the SetActiveFigVal |
|
|
Don't set FDeleting to False in method Change but in KeyDown after the inherited call. I think a solution is to change FDeleting to an Integer. Increase it where FDeleting is set to True, decrease it where FDeleting is set to False. Or keep FDeleting as a Boolean but only set it to false in the same procedure where it is set to true. If you press [BACKSPACE] if the cursor is on a separator, the code of Mask.pas simulates another [BACKSPACE] press, thus Change is called twice. edited on: 06-16-04 06:06 |
|
|
> I think a solution is to change FDeleting to an Integer. Increase it where > FDeleting is set to True, decrease it where FDeleting is set to False. Sounds reasonable. I hope to have some time to have a look at your recent changes and dive back in by next week. > Don't set FDeleting to False in method Change but in KeyDown after the > inherited call. Wouldn't it be safer to do that in KeyUp? The user might keep the backspace key pressed... > If you press [BACKSPACE] if the cursor is on a separator, the code of > Mask.pas simulates another [BACKSPACE] press, thus Change is called twice. Ah, that'd explain it. Still, I'm wondering why it doesn't happen here... |
|
|
>> Don't set FDeleting to False in method Change but in KeyDown after the >> inherited call. > >Wouldn't it be safer to do that in KeyUp? The user might keep the backspace key >pressed... Yes, I guess so. It depends on how many assumptions you want to make: If you set FDeleting to False in method Change, you assume Change is called only once per keypress. If you set FDeleting to False in KeyDown where you set it to True, you assume that Change is not called later in the key pushing cycle (KeyPress, KeyUp) (This is true AFAICS, but might change offcourse). If you keep the backspace key pressed, KeyDown is repeatedly called, thus FDeleting will be set to True and False repeatedly. So this should still work. edited on: 06-16-04 06:39 |
|
|
>Sounds reasonable. I hope to have some time to have a look at your recent >changes and dive back in by next week. Okay, I'll change it now, adjust it anyway you like later on. |
|
|
Fixed AFAICT. Thanks Remko! |
- Anonymous
