CalcEdit shown centered on the form when it should be under the Edit Control lazarus / 10-Designer ---------------------------------------------------------------------- Ever · 2016-03-30 02:06 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 · 2016-03-30 03:15 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 · 2016-03-30 05:04 Quote@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][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i uses LCLType, LCLIntf; procedure TForm1.CalcEdit1ButtonClick(Sender: TObject);begin  Timer1.Enabled := True;end; procedure TForm1.Timer1Timer(Sender: TObject);var  P: TPoint;begin  if (Screen.ActiveCustomForm.Handle <> Self.Handle) then  begin    Timer1.Enabled := False;    P.X := CalcEdit1.Left;    P.Y := CalcEdit1.Top + CalcEdit1.Height + 3;    P := ClientToScreen(P);    SetWindowPos(Screen.ActiveCustomForm.Handle, 0,  P.X,  P.Y,  0,  0,  SWP_NOSIZE);  end;end; PS: Although the code works fine, please don't take it too seriously. ---------------------------------------------------------------------- Bart · 2016-03-30 09:55 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 · 2016-03-30 13:07 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 · 2016-03-30 15:36 Put a feature request in Mantis and assign it to me. Bart ---------------------------------------------------------------------- Bart · 2016-03-31 13:17 Implemented DialogPosition, DialogLeft and DialogTop in r52094. Bart ---------------------------------------------------------------------- balazsszekely · 2016-03-31 17:05 @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 · 2016-03-31 17:59 He posted it in Mantis categorie, where I have no rights. Bart ---------------------------------------------------------------------- wp · 2016-04-01 11:00 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 · 2016-04-01 11:45 Quote from: wp on April 01, 2016, 01:00:56 pmI 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 · 2016-04-01 13:11 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 · 2016-04-01 13:40 Quote from: wp on April 01, 2016, 03:11:25 pmAnd 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 · 2016-04-02 19:40 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 · 2016-04-02 22:00 Quote from: wp on April 02, 2016, 09:40:25 pmI 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. Quote from: wp on April 02, 2016, 09:40:25 pmAs 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 ---------------------------------------------------------------------- Ever · 2016-04-05 03:21 Excuse my lack of knowledge but I'm pretty novice at this, where I see the correction made by Bart r52094. No where to get it to implement it. Thank you ---------------------------------------------------------------------- balazsszekely · 2016-04-05 04:09 Quote@everjdelgadoch  Excuse my lack of knowledge but I'm pretty novice at this, where I see the correction made by Bart r52094. No where to get it to implement it. You have two choices:   1. Wait for a stable release   2. Download and use lazarus trunk If you choose the second one, you need a SVN client, like tortoise: https://tortoisesvn.net/downloads.html For more details, please read this: http://wiki.freepascal.org/Installing_Lazarus#Installing_from_source_2 . Feel free to ask more questions if you like. ---------------------------------------------------------------------- Bart · 2016-04-05 12:43 These chances will not be merged to 1.6 branch since they are not fixes (w.r.g. CalcEdit) but just improvements. Also the EditButton has been refactored completely in trunk, which makes merging almost impossible. Bart ---------------------------------------------------------------------- Ever · 2016-04-05 20:40 Thanks for the info. But I've noticed a little detail with this. This whole problem with the controls is happening to me with projects I did in Lazarus 1.4 and for some improvement perform Lazarus recompile with 1.6, from that recompilation such controls behaved that way. Now, I just started developing a new project with Lazarus 1.6 and I have placed these controls on a form and their behavior is correct encuanto to the position thereof with respect to the edit control, since not centered on screen . The change from version 1.4 to 1.6 may have influenced somehow in such behavior? ---------------------------------------------------------------------- Bart · 2016-04-06 09:08 I really have no idea. Bart