View Issue Details

IDProjectCategoryView StatusLast Update
0001841JEDI VCL00 JVCL Componentspublic2004-06-23 00:43
ReporterxerkanAssigned Toogiesen 
PrioritynormalSeveritytweakReproducibilityalways
Status resolvedResolutionfixed 
Product Version 
Target VersionFixed in Version 
Summary0001841: Error when erasing date in JvDatePickerEdit
DescriptionIf flocks a date in the JvDatePickerEdit component with the key of backward movement instead of erasing a selection, the date automaticamente changes to "1/1/" and when trying to leave the component it leaves a message to you error saying that the date is not been worth
Additional InformationSi borras una fecha en el componente JvDatePickerEdit con la tecla de retroceso en vez de borrar una seleccion, la fecha automaticamente se cambia al " 1/ 1/" y al intentar salir del componente te sale un mensaje de error diciendo que la fecha no es valida
TagsNo tags attached.

Activities

2004-06-08 07:53

 

Captura.gif (5,182 bytes)
Captura.gif (5,182 bytes)

xerkan

2004-06-08 08:11

reporter   ~0004500

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

ogiesen

2004-06-09 00:47

developer   ~0004505

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.

xerkan

2004-06-09 04:33

reporter   ~0004506

i put a video with error reproduce

2004-06-09 04:33

 

video.avi (79,872 bytes)

ogiesen

2004-06-09 04:48

developer   ~0004507

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?

xerkan

2004-06-09 08:02

reporter   ~0004510

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;

anonymous

2004-06-10 00:12

viewer   ~0004514

"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...

xerkan

2004-06-10 02:10

reporter   ~0004529

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

remkobonte

2004-06-16 05:53

developer   ~0004571

Last edited: 2004-06-16 06:06

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

ogiesen

2004-06-16 06:08

developer   ~0004572

> 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...

remkobonte

2004-06-16 06:29

developer   ~0004573

Last edited: 2004-06-16 06:39

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

remkobonte

2004-06-17 13:07

developer   ~0004580

>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.

ogiesen

2004-06-23 00:43

developer   ~0004599

Fixed AFAICT. Thanks Remko!

Issue History

Date Modified Username Field Change
2004-06-08 07:51 xerkan New Issue
2004-06-08 07:53 xerkan File Added: Captura.gif
2004-06-08 08:11 xerkan Note Added: 0004500
2004-06-09 00:24 ogiesen Status new => assigned
2004-06-09 00:24 ogiesen Assigned To => ogiesen
2004-06-09 00:47 ogiesen Note Added: 0004505
2004-06-09 04:33 xerkan Note Added: 0004506
2004-06-09 04:33 xerkan File Added: video.avi
2004-06-09 04:48 ogiesen Note Added: 0004507
2004-06-09 08:02 xerkan Note Added: 0004510
2004-06-10 00:12 anonymous Note Added: 0004514
2004-06-10 02:10 xerkan Note Added: 0004529
2004-06-16 05:53 remkobonte Note Added: 0004571
2004-06-16 06:06 remkobonte Note Edited: 0004571
2004-06-16 06:08 ogiesen Note Added: 0004572
2004-06-16 06:29 remkobonte Note Added: 0004573
2004-06-16 06:39 remkobonte Note Edited: 0004573
2004-06-17 13:07 remkobonte Note Added: 0004580
2004-06-23 00:43 ogiesen Status assigned => resolved
2004-06-23 00:43 ogiesen Resolution open => fixed
2004-06-23 00:43 ogiesen Note Added: 0004599