CalcEdit shown centered on the form when it should be under the Edit Control

[Ever]

When upgrading to 1.6 lazarus, controls such as CalcEdit and TDateEdit show the calculator or calendar in the center of the form, and not under the same control as usual.

Any suggestions ... Annex image

PS: Using Windows 10

[Mike.Cornflake]

I've just run a small test here (Win 8 64bit, Laz trunk).  DateEdit and TimeEdit both work fine.  I can confirm though that CalcEdit behaves as you describe. 

However, CalcEdit does behave the same as TColourButton, TFilenameEdit and TDirectoryEdit...  So I'm not sure how Calc Edit is supposed to behave. 

If the behaviour has indeed changed, then lodge a report in Mantis... (Lazarus - Bug Tracker on the left)

[balazsszekely]

@everjdelgadoch
Any suggestions ...

I never used TCalcEdit so I have absolutely no idea how it behaved in the past, or how it should behave.
As a funny solution, drop a TTimer to your form, set Enabled property to False, Interval to 100. Create the OnButtonClick event(TCalcEdit):

Code: Pascal  [Select][+][-]

1. uses LCLType, LCLIntf;
2.  
3. procedure TForm1.CalcEdit1ButtonClick(Sender: TObject);
4. begin
5.   Timer1.Enabled := True;
6. end;
7.  
8. procedure TForm1.Timer1Timer(Sender: TObject);
9. var
10.   P: TPoint;
11. begin
12.   if (Screen.ActiveCustomForm.Handle <> Self.Handle) then
13.   begin
14.     Timer1.Enabled := False;
15.     P.X := CalcEdit1.Left;
16.     P.Y := CalcEdit1.Top + CalcEdit1.Height + 3;
17.     P := ClientToScreen(P);
18.     SetWindowPos(Screen.ActiveCustomForm.Handle, 0,  P.X,  P.Y,  0,  0,  SWP_NOSIZE);
19.   end;
20. end;

PS: Although the code works fine, please don't take it too seriously.

[Bart]

AFAIK CalcEdit just launches a modal dialog.
The line:

Code: [Select]

  Position:=poScreenCenter;
has been in there since the frist implementation by Alexey in r49688 (as everjdelgadoch could have easily found out by himself).

Bart

[zeljko]

That's an issue. It must have ability to show at desired place. Maybe adding buddy control as property and then calculate position if buddy control <> nil. Position of calcedit can be below but also above if control is at the bottom of the screen.

[Bart]

Put a feature request in Mantis and assign it to me.

Bart

[Bart]

Implemented DialogPosition, DialogLeft and DialogTop in r52094.

Bart

[balazsszekely]

@Bart
Please assign it to you and mark as resolved(http://bugs.freepascal.org/view.php?id=29934), I guess the OP opened the issue.

[Bart]

He posted it in Mantis categorie, where I have no rights.

Bart

[wp]

I checked the new properties. Definitely better. But: Now I still have to set the DialogTop and -Left properties to position the calculator underneath the edit. Sometimes (with anchors set, or the edit too close to the screen borders) it is not straightforward to find the correct coordinates. My idea: If the DialogPosition is poDefault calculate the correct dialog position and use them in place of the DialogTop/Left which should be valid only for poDesigned.

Another issue with the TCalcEdit: The button "ok" should be the default button of the form, i.e. close the dialog upon "Enter" - I had to look for quite some time until I found the unconveniently positioned ok button.

And: Why are the captions of the the calculator buttons bold? In my eyes this screws up a consistent user interface. At least, there should be an option to turn the bold type-face off.

[Zoran]

I checked the new properties. Definitely better. But: Now I still have to set the DialogTop and -Left properties to position the calculator underneath the edit. Sometimes (with anchors set, or the edit too close to the screen borders) it is not straightforward to find the correct coordinates. My idea: If the DialogPosition is poDefault calculate the correct dialog position and use them in place of the DialogTop/Left which should be valid only for poDesigned.

WP, test the behaviour of TDateTimePicker.  Test when close to all four screen edges, especially when close to task bar.
Do you think it has the positioning of the calendar form which you want for these controls?
If so, I could take a look at this and create the patch which will make the positioning just like TDateTimePicker does (when DialogPosition is poDefautl).

[wp]

TDateTimePicker is perfect.

Some more issues related (just to document them, maybe you or somebody else wants to address them as well , if not I can write bugreports, of course...):

TDateEdit's calender is strangely offset to the left if the edit is too close at the screen right. Moveover, if the edit is near the screen bottom edge the popup calendar overlaps with the Windows taskbar because the calender is drawn below the edit, it should be above it.

TTimeEdit's horizontal position near the right screen edge is correct, but vertically the popup form also overlaps with the Windows taskbar for the same reason.

TTimeEdit has the additional issue that the gray hour bar at the top shows only the second row, probably if the current hour is after noon time. The first row with the hours 0-11 come in by using the mouse wheel (Win 7, standard pixel densitiy, i.e. no high dpi). (see screenshot)

And TTimeEdit raises a SIGSEGV at program exit: Press the time icon to open the time input form, press ALT (I wanted to take a screen shot with ALT-Print). The form closes. But when the program exits, the SIGSEGV is reported.

[Bart]

And TTimeEdit raises a SIGSEGV at program exit: Press the time icon to open the time input form, press ALT (I wanted to take a screen shot with ALT-Print). The form closes. But when the program exits, the SIGSEGV is reported.

This is a know issue: http://bugs.freepascal.org/view.php?id=28404

Bart

[wp]

I played a bit with positioning of the CalcDialog underneath the edit as I proposed above. No - not a good idea, looks awful, at least in Windows 7. This is because, unlike the combobox dropdown boxes, this is a dialog with the broad Win7 border and the border icons.

Moreover, I found the global variables cCalculatorFontName (string = 'MS Sans Serif') and cCalculatorFontStyle (= [fsBold]) in the unit CalcForm. Therefore, it is possible to switch to normal font and replace the old-time MS Sans Serif font.

[EDIT]
As for the TTimeEdit positioning issue, I just posted a bug report (http://bugs.freepascal.org/view.php?id=29949).

[Bart]

I played a bit with positioning of the CalcDialog underneath the edit as I proposed above. No - not a good idea, looks awful, at least in Windows 7. This is because, unlike the combobox dropdown boxes, this is a dialog with the broad Win7 border and the border icons.

Which is exactly why I implemented it NOT like e.g. TDateEdit, but just implemented the propertis to make it as you want.

As for the TTimeEdit positioning issue, I just posted a bug report (http://bugs.freepascal.org/view.php?id=29949).

See my comments in that report, and continue that discussion there.

Bart