You are not logged in.
Pages: 1
Аnother suggestion for SynTaskDialog.pas/SynTaskDialog.rc - rename resources 'btnOk' and 'btnArrow' into something a little less popular, such as 'SynTDbtnOk' and 'SynTDbtnArrow'. With present names it is likely to face with a conflict of resource names (I have faced with such situation yet).
I think that in this case, it is sufficient to replace inside TTaskDialog.Execute this line
Config.cxWidth := aWidth;
with
Config.cxWidth := round(aWidth / (LOWORD(GetDialogBaseUnits()) / 4));
since it is the system dialog (is uses system font) so it is permissible to use GetDialogBaseUnits in this case.
Hi.
I'm trying to use TTaskDialog with custom width (auto width is not suitable for me) and aNonNative=False.
Test code is:
Task.Inst := 'Content';
Task.Buttons := 'Button1'#13'Button2';
Task.Execute([],100,[tdfUseCommandLinks],tiWarning,tfiInformation, 0, 480);
When I use it under windows XP it works well, but under Windows 7 message window width is getting too big.
I think the reason is that when you emulate (under Windows XP) the Width parameter indicates the width of the window in pixels, but when using TaskDialogIndirect cxWidth is in Dialog Units (accoding to documentation).
I've checked for "Single" type and precision=8. Difference between values before ExtendedToStr and after StrToFloat is not exceed 1LSB and have no trends to "drift".
Thank you
I understand. Some time ago, at my request, you have added a "Single" type support when creating JSON (thank you). May be there is some way to make precision customizable without breaking the code optimization. May be to make SINGLE_PRECISION and DOUBLE_PRECISION not a constants but a variables or to provide some another interface to this values. I think, other people too may encounter the same problem, not just me.
You believe that a reference value for computing floating point is a string. I think that the number (binary representation) is more important. Let me explain my position. I plan to store in the database a set of coordinates in JSON format. Initially the coordinates are numbers ("Single" type). The user should be able to change the coordinates of individual points, leaving the rest unchanged. As a result of coordinate will periodically be converted from JSON (text) to numeric form and Vice versa. I am afraid that as a result of errors discussed above after multiple conversions coordinates will started to "drift" each time the user edits the data.
With increased accuracy data can be easy converted multiple times without loss of information.
ab
Your example contain an implicit assumption that number "9.999999999999997" can be converted to "double" type without error. But it's not. The compiler assigns to variable a value about "9.99999999999999645", so "9.999999999999996" is the best approach for it than "9.999999999999997".
You can check it with the following example:
var
v1, v2: double;
s: string;
begin
v1 := 9.999999999999997;
s := ExtendedToStr(v1, DOUBLE_PRECISION); // DOUBLE_PRECISION=15
v2 := StrToFloat(s);
if v1 <> v2 then
ShowMessage('Differ1');
s := ExtendedToStr(v1, DOUBLE_PRECISION + 1);
v2 := StrToFloat(s);
if v1 <> v2 then
ShowMessage('Differ2');
end;
You will see only "Differ1" message.
Hi.
I use "Single" type to store numbers in JSON. I recently discovered that in the conversion of such numbers to the text form precision is lost (if to convert the resulting text back to a number, the result is differ from the initial).
Example:
var
v1, v2: Single;
i: integer;
s: string;
begin
i := $C120000B;
v1 := pSingle(@i)^;
s := SynCommons.ExtendedToStr(v1, SINGLE_PRECISION{ + 1});
v2 := StrToFloat(s);
if v1 <> v2 then
raise Exception.Create('Differ!');
end;
And those numbers enough numerous.
The solution is proposed here https://randomascii.wordpress.com/2012/ … -digits-2/
I propose to increase the SINGLE_PRECISION constant from 8 to 9 (I've checked, this fixes the inaccuracy). Maybe DOUBLE_PRECISION should also be increased to 17, as indicated in the article.
1. I think I have found a little error in htm2pdf application located inside mORMot\HtmlView\htm2pdf\Html2Pdf.pas
This file contains the following code (line #102):
LMarginY := -Centimeters2Points(MarginTop);
But I think it should be (no "-" char):
LMarginY := Centimeters2Points(MarginTop);
2. Also I have incorrectly looking PDF when trying to convert the following htm file using htm2pdf.
Source file (htm): https://drive.google.com/open?id=0Bzzn1 … authuser=0
Result (pdf): https://drive.google.com/open?id=0Bzzn1 … authuser=0
It is seen that in the pdf on the 2nd and 3rd page spoiled the table header (color shift and additional horizontal line), and on the last page from the end table before the end of the page are drawn two vertical lines. I don't know what to think, because when I print the same htm file on the printer (print using the same htmlview component), the result is obtained without these artifacts:
(result of printing to a virtual printer, tif): https://drive.google.com/open?id=0Bzzn1 … authuser=0
In documentation for constructor THttpApiServer.Create when describing CreateSuspended parameter I think TRUE and FALSE values are swapped.
now we have
if you override this contructor, put the AddUrl() methods within, and you can set CreateSuspended to TRUE
- if you will call AddUrl() methods later, set CreateSuspended to FALSE, then call explicitely the Resume method, after all AddUrl() calls, in order to start the server
but should be
if you override this contructor, put the AddUrl() methods within, and you can set CreateSuspended to FALSE
- if you will call AddUrl() methods later, set CreateSuspended to TRUE, then call explicitely the Resume method, after all AddUrl() calls, in order to start the server
Your newest version works fine both with "Single" type and with adding objects to array. Thank you.
I tried the latest version of "SynCommons.pas" from http://synopse.info/fossil/info/846978294b
The behaviour with "Single" and "Double" types is improved.
Unfortunately, with new version of "SynCommons.pas" the following code starts to cause error "Invalid pointer operation":
var
v1, obj: Variant;
begin
v1 := _Arr([]);
obj := _Obj(['id', 1]);
v1.Add(obj);
caption := VariantSaveJSON(v1);
end;
Also after error FastMM4 reports that memory leak appears.
Previous versions of "SynCommons.pas" have no problems with such code.
Thanks again. I have adjusted the program according to your advice.
Think you very much. The new version do exact what I want with variables of "Single" type.
Sorry for molestation. But I think you would resolve the error, about which I wrote above. It still alive. The following code:
var
s: Double;
v1: Variant;
begin
v1 := _Arr([]);
s := 1.23456;
v1.Add(s);
caption := VariantSaveJSON(v1);
end;
cause an error "TTextWriter.AddVariantJSON(VType=16389)" when variable "s" has type "Single" or "Double". Only declaration "s: Extended" cause no error. I think this is a serious error. Few people use the type "Single". But the type "Double" is very popular (I think it is more popular than "Extended" as for the reason of compatibility with "double" from "C" language and for the reason that its length is a multiple of 8 bytes, which is beneficial to program performance.
Thank you for your answer. I will use typecasting to WideString when string variables can contain national characters.
I can give an example of task when I want to use "single" precision. I am writing an application to handle geodata. End-point devices use GPS-receivers to determine their location. Then they send data to server using GSM channel. My application requests data from the server and shows objects on a map.
GPS receivers send their data using NMEA format. This format uses only 8-9 significant digits to represent latitude and longitude. So "single" type was chosen for storing coordinates.
Client application communicate with the server using JSON format. And I see that when server sends coordinates It uses significantly more digits than necessary. I the future when number of end-point devices grows JSON message will have large extra length and lead to excessive internet traffic.
I looked at the source "SynCommons.pas" and found that the code provides for the possibility to use a "Single" (for example, declared and used constant "SINGLE_PRECISION"), but did not understand how to use this feature. I have tried several ways but got the same result.
Hi.
I use "Single" float numbers in my application.
But when I try to add their values to JSON object I get double (or extended) precision in the result JSON. So JSON has excess data.
e.g.
var
s: Single;
v1: Variant;
begin
s := 2.6666666;
v1 := _Obj(['label', s]);
caption := VariantSaveJSON(v1);
end;
As a result caption will contain "2.666666650772095"
So I have found a strange thing: when I try to add "Single" or "Double" variable to array:
v1 := _Arr([]);
v1.Add(s);
I get an error TTextWriter.AddVariantJSON(VType=16388). There is no error when only if I use "Extended" type.
PS: I use Delphi7
Hi.
I use Delphi7.
I use Russian chars for some JSON values.
For the following code:
var
V1: variant;
begin
v1 := _Arr([]);
for i := 0 to 1 do
v1.Add('Some words in Russian');
caption := VariantSaveJSON(v1);
end;
as a result caption will contain UTF8-encoded string. But if I change the line inside "for" cycle to
v1.Add(_Obj(['label', 'Some words in Russian']));
caption will contain an unencoded string.
Pages: 1