jarto

Now it should be possible for everyone to use SmartUpdate with the development-channel.

17.11.2018 RTL: Changes to handling of Cursor: Style definitions moved from basic html elements to control styles GetCursor and SetCursor can now be overridden Bug fixes to how many controls handle cursor. Especially TW3Label. Themes: Add missing styles TW3CheckBox, TW3CheckMark, TW3RadioButton, TW3RadioToggle and TW3RadioGroup Two new backgrounds: TW3DecorativeListItemBackground and TW3TransparentBackground RTL optimizations to creation of controls, GetBoundsRect, SetBounds, MoveTo and SetSize. Bug fix to SmartCL.Graphics.pas: Changing of canvas font, size and styles did not work. Bug fix to System.DateUtils.DecodeDate. IDE: Delete key works now Search dialog and other dialogs. Bug fix: Internal Browser Window showed only a white screen if Execute was clicked while it was open. Compiler: Now(), EncodeDate() and EncodeTime() returns now the same values as Delphi and FPC All time/date -functions fixed to work with the new TDateTime-values

The Development-channel in SmartUpdate contains all the latest changes in Smart Mobile Studio. It's a good channel to follow for those who want all the new features and bug fixes right away, instead of waiting for the next formal release. To follow the Development-channel: Make a new folder and add: SmartUpdate.exe Your own user.lic from your current Smart Mobile Studio folder. To get all the latest changes in the Development-channel: Run: SmartUpdate /changechannel /showhidden When asked for which channel to follow, choose Development The purpose of this topic is to inform about all the new features and fixes.

I dug around and found out that I actually can fix those "buggy" functions in the compiler without having to upgrade to a newer version of DWScript. I only have IncMonth to fix any more. The root cause of the problem is the way javascript dates work. When you build a date from day, month and year, the result depends on your time zone. I guess it builds the date as UTC and then views it from your location. So, while it's 01.12.2018 at 00:00:00 in London, it's still 30.11.2018 in USA. And when you call DayOf on that, you get 30 instead of 1. This affects about 10 other functions as well, including FormatDateTime and DateTimeToStr and TimeToStr. I'll make sure to test this all properly and then release an update. Once it's done, I'm super happy to get rid of these problems.

Actually, there's nothing wrong with DayOf. Here we see the problem again from the buggy Now-function in the compiler. It probably returned in your time zone a TDateTime that was still on Nov 15th. Before a fix is done in the compiler, here's a way to make sure that the TDateTime that Now returns is correct: function FixDateTime(const ADate: TDateTime): TDateTime; begin var TzHours:=StrToIntDef(FormatDateTime('h',43436),0); var TzMinutes:=StrToIntDef(FormatDateTime('nn',43436),0); var TzCorrection:=System.DateUtils.EncodeTime(TzHours,TzMinutes,0,0); result:=ADate+TzCorrection; if TzCorrection>0.5 then result:=result-1; end; Use like this: var TimeNow:=FixDateTime(Now); After this, you have a TDateTime that is compatible with Delphi, Lazarus and functions in System.DateUtils. As FormatDateTime is also from the compiler and not compatible, use these formatting functions instead: function MyDateToStr(const ADate: TDateTime): String; var d,m,y: Integer; begin System.Dateutils.DecodeDate(ADate,y,m,d); result:=Format('%.2d',[d])+'.'+Format('%.2d',[m])+'.'+Format('%.4d',[y]); end; function MyTimeToStr(const ADate: TDateTime): String; var h,m,s,ms: Integer; begin System.Dateutils.DecodeTime(ADate,h,m,s,ms); result:=Format('%.2d',[h])+':'+Format('%.2d',[m])+'.'+Format('%.2d',[s]); end; Make sure to use these formatting functions with the fixed TDateTime and not the value that "Now" returns. And also use the fixed TDateTime with all the functions in System.DateUtils.

Thanks. Gonna have a look at this tonight.

Ok, I found a bug in System.DateUtils.DecodeDate. It decodes 43435 as 31.11.2018 while it should be 1.12.2018. Inc(QTX,Higher); M := 1; repeat <----- change this to: While True do begin Higher := CNT_DaysInMonthData[IsLeapYear(QTX)][M]; if Lower < Higher then Break; Dec(Lower, Higher); Inc(M); until lower < Higher; <------ change this to: end; That's at lines 320-326 However, this is not the full story. There still are issues with the compiler's date functons and let me explain here a bit: EncodeDate builds a TDateTime from year, month and day, just like in Delphi. TDateTime is a float where the integer part is the days and fraction is for time. So when you do a EncodeDate(2018,12,1), it should return a clean integer: 43435 In Delphi or Lazarus FloatToStr(EncodeDate(2018,12,1)) gives 43435 WriteLn(System.DateUtils.EncodeDate(2018,12,1)) gives 43435 Compiler's own WriteLn(EncodeDate(2018,12,1)) gives in my location 43434.83333333333 Where you live, it's probably another number. But the bottom line is: It should not be a weird number like that and most definitely, it should not depend on where you run the program. Now, FormatDate, DateToStr and other functions that are built into the compiler are tuned so that they actually work with those weird and wrong TDateTimes. So you usually don't notice that something is wrong before you start mixing functions. What I can do now is to fix the DecodeDate, but fixing the bug in the compiler itself needs some more work. To avoid getting in trouble with compiler's DateToStr, you might want to use another DateToStr: function MyDateToStr(const ADate: TDateTime): String; var d,m,y: Integer; begin System.Dateutils.DecodeDate(ADate,y,m,d); result:=Format('%.2d',[d])+'.'+Format('%.2d',[m])+'.'+Format('%.4d',[y]); end;

When you call the compiler's broken EncodeDate, it returns a TDateTime, which is not an integer. That's because it tries to do some time zone calculations, which simply do not make sense. So if you add a WriteLn(ADate), you will see that the correct version returns 43435 while the broken one returns a fractional number. Try by keeping System.DateUtils in uses and calling EncodeDate: System.DateUtils.EncodeDate() And also try by using System.DateUtils.DecodeDate()

@Czar Just had a look and found the problem. The code that was in TW3CanvasFont.WriteFontInfo had to be in ReadFontInfo. Also, WriteFontInfo needed to be constructed from the internal variables. Edit: Fixed now. Gonna be in next update.

Add System.DateUtils to your uses-clause. There are bugs in TDateTime in the DWS compiler version which is currently used. By using System.DateUtils, you can avoid those.

@IElite Yeah, I noticed that the styles for TW3CheckBox, TW3CheckMark, TW3RadioButton, TW3RadioToggle and TW3RadioGroup were missing. I am adding them now while I do the Cursor-changes that I mentioned in the TW3Label -discussion.

Yeah, I had a look and the cursors are not done in a sensible way in the RTL at the moment. Background: TW3Label consists of the control itself (let's call it background) and an inner div, which contains the text itself. This is to be able to align the text horizontally and vertically. Currently the style sheet sets the cursor value as "default" for every div. So, when the background cursor is changed, the inner div in the label still has it's cursor as default, which is the arrow. It's not only here, but basically with any component that has inner sub controls etc. IMHO we need to remove the default cursor value from the style sheet or set it as "inherit". At that point the inner div gets the same cursor as it's parent. But this also involves going through all the other styles and making sure that they have sensible cursor values in the style sheet. Some styles need to have "default" and some "inherit" and maybe some "auto". And after that we need to make sure that more complex controls actually set the cursor of their sub controls properly. So it will take some work, but I'm going to experiment and find the solution what works best. Edit: Cursor issues are now fixed and will be in the next update.

procedure TW3Calendar.NextMonth; var y,m,d:integer; begin decodedate(fCalendarDate, y,m,d); if M <> 12 then inc(m) else begin m:= 1; inc(y); end; //Make sure the day is not too big. uses System.DateUtils var MaxD:=DaysInMonth(m); if d>DaysInMonth(MaxD) then d:=MaxD; fCalendarDate:= encodeDate(y,m,d); end;

fCalendarDate:= encodeDate(y,m,d); Are you sure that this one is calling the setter method? Usually Fanything means the variable itself.

Do you see any errors when you open DevTools?