[fpc-pascal] Patch: new XML export for FCL-DB, was: SDFDataset multiline support: request for a look at patch+test, issue 17285
On 22-7-2011 14:01, Michael Van Canneyt wrote: On Fri, 22 Jul 2011, Reinier Olislagers wrote: snip BigChimp PS: Shameless plug: Now working on fcl-db export to Unicode XML with XSD support for better interoperability with .Net (ADO.NET) and Microsoft Access... I will be glad to see your contribution :-) Michael. Michael everyone else, I've uploaded initial implementation in issue 19790. Can't get UTF8 working would appreciate people having a look at it. (So my earlier estimate of having something by next week might still be valid ;) Tested export using included test program; import worked in Access XP/2002. Other less important tests/things to do are included in bug report and source code. If you guys can help me get UTF8 support working, and the code is approved by the devs, I think we can add this to FCL-DB ;) Thanks, BigChimp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE : [fpc-pascal] Patch: new XML export for FCL-DB, was: SDFDataset multiline support: request for a look at patch+test, issue 17285
I've uploaded initial implementation in issue 19790. Can't get UTF8 working would appreciate people having a look at it. (So my earlier estimate of having something by next week might still be valid ;) TDOMDocument.CreateTextNode expects a DOMString which is WideString. The windows string to unicode conversion assumes the string is ansi. Use: FOutputDoc.CreateTextNode(UTF8Decode(EF.Field.AsString)); BTW importing the output xml in access 2002 results in access crashing. I'm looking into that. Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : [fpc-pascal] Patch: new XML export for FCL-DB, was: SDFDataset multiline support: request for a look at patch+test, issue 17285
On 23-7-2011 12:23, Ludo Brands wrote: Hi Ludo, Thanks for the help. TDOMDocument.CreateTextNode expects a DOMString which is WideString. The windows string to unicode conversion assumes the string is ansi. Use: FOutputDoc.CreateTextNode(UTF8Decode(EF.Field.AsString)); UTF8Decode would go from UTF8/Unicode to ANSI - but CreateTextNode expects UTF16? I don't get it. RTFM for a change: ok, UTF8Decode decodes to a widestring (presumably UTF16 in Windows). I'll give it a go. BTW importing the output xml in access 2002 results in access crashing. I'm looking into that. Access XP SP3, 10.6771.6870 crashed for me too in earlier versions of the code. It worked for the code I uploaded. Just tried it again with the test results output, and now it crashes for me, too... I'll ask on an Access list to see if this is expected and what can be done... ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
TR : RE : RE : [fpc-pascal] Patch: new XML export for FCL-DB, was: SDFDataset multiline support: request for a look at patch+test, issue 17285
-Message d'origine- De : Ludo Brands [mailto:ludo.bra...@free.fr] Envoyé : samedi 23 juillet 2011 13:24 À : 'Reinier Olislagers' Objet : RE : RE : RE : [fpc-pascal] Patch: new XML export for FCL-DB, was: SDFDataset multiline support: request for a look at patch+test, issue 17285 Doesn't crash now for me, but I do get these errors in Access now (If you don't speak Dutch: Regel=Line, Onbekende eigenschap=Unknown property, Syntaxisfout: syntax error): Same in flemish ;) XML-tekst Foutbericht Regel 4: name Onbekende eigenschap Regel 18: minOccurs Syntaxisfout Regel 23: minOccurs Syntaxisfout od:minOccurs should be minOccurs Regel 25: baseOnbekende eigenschap Regel 30: minOccurs Syntaxisfout Regel 32: baseOnbekende eigenschap Regel 37: minOccurs Syntaxisfout Regel 42: minOccurs Syntaxisfout Regel 44: baseOnbekende eigenschap Regel 50: minOccurs Syntaxisfout I'll have a look at those as well.. Also, your fix for UTF8 support for data works. Now I'm going to have a look at the field names. Thanks, Reinier/BigChimp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
TR : RE : RE : [fpc-pascal] Patch: new XML export for FCL-DB, was: SDFDataset multiline support: request for a look at patch+test, issue 17285
-Message d'origine-
De : Ludo Brands [mailto:ludo.bra...@free.fr]
Envoyé : samedi 23 juillet 2011 13:35
À : 'Reinier Olislagers'
Objet : RE : RE : RE : [fpc-pascal] Patch: new XML export for FCL-DB, was:
SDFDataset multiline support: request for a look at patch+test, issue 17285
Regel 4: name Onbekende eigenschap
215
// Add table list. If we're exporting an FPC dataset, there
// will only be one table.
FXSDTableListNode := FOutputDoc.CreateElement('xsd:element');
Was
FXSDTableListNode := FOutputDoc.CreateElement('element');
Regel 18: minOccurs Syntaxisfout
Regel 23: minOccurs Syntaxisfout
Regel 25: baseOnbekende eigenschap
228
RestrictionNode := FOutputDoc.CreateElement('xsd:restriction');
Was
RestrictionNode := FOutputDoc.CreateElement('xsd.restriction');
The decimal point needs also to be localised ;(
Ludo
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: TR : RE : RE : [fpc-pascal] Patch: new XML export for FCL-DB, was: SDFDataset multiline support: request for a look at patch+test, issue 17285
Sorry, didn't realise Ludo had sent his replies to the list as well.
Summary and item for discussion below:
On 23-7-2011 13:38, Ludo Brands wrote:
-Message d'origine-
De : Ludo Brands [mailto:ludo.bra...@free.fr]
Regel 4: nameOnbekende eigenschap
snip helpful corrections Was
RestrictionNode := FOutputDoc.CreateElement('xsd.restriction');
Thanks Ludo, have fixed those.
The decimal point needs also to be localised ;(
Ludo
You are correct. I had explicitly left it as a . - must have taken a ,
for a . when tired.
What a ridiculous idea, to generate different exports for the same data
depending on what country you are in.
I might just leave it in US format as a . - this will at least
create a consistent format and allow import by US/Anglophone countries.
What do you
think?
Better yet, I'll have a look at how newer versions of Access and ADO.NET
do this,
maybe MS have fixed this since then.
If anyone wants to try exporting to XML with inline XSD in newer
versions of Access, please do; you can e.g. paste the XML on pastebin.ca
and send me a reminder. Thanks.
What's also strange is that currency fields don't have a currency symbol
(e.g. €); I've got Dutch settings with . as thousands separator - no
trace of a . in currency output. But it does output , as a decimal
marker, not .
Weird.
Once again, I'll look at how newer Access versions and ADO.Net do this.
Thanks,
Reinier
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] TCustomListBox Sort Query
I've got a file list box thats based around TCustomListBox , i noticed it can be sorted - i'm using it to display filenames but it would be really great to be able to sort it via timedate of the file Is there another control thats like this that i could use ? i was thinking of storing the date information in the object and over riding the update sort in the win32 widgetset. Any thoughts welcome. Justin Smyth___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE : RE : RE : RE : [fpc-pascal] Patch: new XML export for FCL-DB, was: SDFDataset multiline support: request for a look at patch+test, issue 17285
Don't know when it started, but at one point messages weren't going to the list anymore. Since my incoming messages are routed by title [fpc-pascal] they still showed up as coming from the list... Hence the confusion. The decimal point needs also to be localised ;( You are correct. I had explicitly left it as a . - must have taken a , for a . when tired. What a ridiculous idea, to generate different exports for the same data depending on what country you are in. At one time, even VBA was localised. You couldn't run scripts created on a french excel on a german excel fe. Actually, I might just leave it in US format as a . - this will at least fix the format and allow import by US/Anglophone countries. What do you think? (Better yet, I'll have a look at how newer versions of Access do this, maybe MS have fixed this since then) DecimalSeparator is set to the system value in Sysutils and correspond to the machines localisation. You shouldn't hardcode it. What's also strange is that currency fields don't have a currency symbol (e.g. €); I've got Dutch settings with . as thousands separator - no trace of a . in currency output. But it does output , as a decimal marker, not . Weird. The currency sign and thousands separators is for display use only. I haven't seen any data format using them. Luckily, that is. The decimal separator is already confusing enough. Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : RE : RE : RE : [fpc-pascal] Patch: new XML export for FCL-DB, was: SDFDataset multiline support: request for a look at patch+test, issue 17285
On 23-7-2011 14:06, Ludo Brands wrote: The decimal point needs also to be localised ;( Actually, I might just leave it in US format as a . - this will at least fix the format and allow import by US/Anglophone countries. What do you think? (Better yet, I'll have a look at how newer versions of Access do this, maybe MS have fixed this since then) DecimalSeparator is set to the system value in Sysutils and correspond to the machines localisation. You shouldn't hardcode it. Well, I want to have the same output regardless of which locale you're in. (Unless there's a really good reason not to do that, or maybe, if there is a way to specify locale in the output XML) So then I should hardcode it, right? (I'm resetting them to their previous settings at the end of the module, but there might be a better way of doing that). Or, quite probably, there's a better way to use FloaltToStr with a . without having to mess with DecimalSeparator. Had a quick look through the documentation but couldn't find anything obvious. Does anyone have any suggestions? The currency sign and thousands separators is for display use only. I haven't seen any data format using them. Luckily, that is. The decimal separator is already confusing enough. Yes, it does simplify things. But there might be a difference between 1 Zimbabwean dollar and 1 Swiss franc - both will display as 1 :( ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
RE : RE : RE : RE : RE : [fpc-pascal] Patch: new XML export for FCL-DB, was: SDFDataset multiline support: request for a look at patch+test, issue 17285
DecimalSeparator is set to the system value in Sysutils and correspond to the machines localisation. You shouldn't hardcode it. Well, I want to have the same output regardless of which locale you're in. (Unless there's a really good reason not to do that, or maybe, if there is a way to specify locale in the output XML) So then I should hardcode it, right? (I'm resetting them to their previous settings at the end of the module, but there might be a better way of doing that). Isn't property FormatSettings: TXMLXSDFormatSettings supposed to be used for this? It has a Property DecimalSeparator. Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : RE : RE : RE : RE : [fpc-pascal] Patch: new XML export for FCL-DB, was: SDFDataset multiline support: request for a look at patch+test, issue 17285
On 23-7-2011 14:40, Ludo Brands wrote: DecimalSeparator is set to the system value in Sysutils and correspond to the machines localisation. You shouldn't hardcode it. Well, I want to have the same output regardless of which locale you're in. (Unless there's a really good reason not to do that, or maybe, if there is a way to specify locale in the output XML) So then I should hardcode it, right? (I'm resetting them to their previous settings at the end of the module, but there might be a better way of doing that). Isn't property FormatSettings: TXMLXSDFormatSettings supposed to be used for this? It has a Property DecimalSeparator. Ludo I think we may misunderstand one another. What I propose: 1. do NOT localize decimal separator in XML output, but keep US format . This has the advantage that export of the same data on any system will lead to the same results. (Disadvantage: Access might barf if a decimal , is suddenly a decimal .) There are 2 more options: 2. Localize decimal separator according to OS locale settings such as Access XP is doing. 3. Follow the FormatSettings setting given in the GUI to determine output type. (Or a combination of these) In cases 1 and 3, I might need to customize the decimal separator for float export. This means (as far as I have been able to find out) tweaking the Sysutils.Formatsettings... Right? In any event, I'll first try and see what newer versions of Access and ADO.NET do... Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: RE : RE : RE : RE : RE : [fpc-pascal] Patch: new XML export for FCL-DB, was: SDFDataset multiline support: request for a look at patch+test, issue 17285
On 23-7-2011 14:40, Ludo Brands wrote: DecimalSeparator is set to the system value in Sysutils and correspond to the machines localisation. You shouldn't hardcode it. Well, I want to have the same output regardless of which locale you're in. (Unless there's a really good reason not to do that, or maybe, if there is a way to specify locale in the output XML) So then I should hardcode it, right? (I'm resetting them to their previous settings at the end of the module, but there might be a better way of doing that). Isn't property FormatSettings: TXMLXSDFormatSettings supposed to be used for this? It has a Property DecimalSeparator. Ludo Ludo, Maybe I misunderstood you: I have now chosen to use . unless the user overrides that in the export FormatSettings. Would this be satisfactory? Also, I've written and uploaded a small VB.Net test program to see the XML output .Net/ADO.NET creates/expects. The output is a bit different than Access XP, but might be quite near newer version of Access. I'm going to try and implement basic support for that. Once I've finished that, I think it's done for now. Thanks for the help, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
: RE : [fpc-pascal] Patch: new XML export forFCL-DB, was: SDFDataset multiline support: request for a look at patch+test, issue 17285
Isn't property FormatSettings: TXMLXSDFormatSettings supposed to be used for this? It has a Property DecimalSeparator. Ludo I think we may misunderstand one another. What I propose: 1. do NOT localize decimal separator in XML output, but keep US format . This has the advantage that export of the same data on any system will lead to the same results. (Disadvantage: Access might barf if a decimal , is suddenly a decimal .) There are 2 more options: 2. Localize decimal separator according to OS locale settings such as Access XP is doing. 3. Follow the FormatSettings setting given in the GUI to determine output type. (Or a combination of these) OK let me more precise: Change function TCustomXMLXSDExporter.CreateFormatSettings: TCustomExportFormatSettings; To function TCustomXMLXSDExporter.CreateFormatSettings: TCustomExportFormatSettings; begin Result := TXMLXSDFormatSettings.Create(True); end; This will initialise Formatsetting to sysutils format settings. In procedure TCustomXMLXSDExporter.DoBeforeExecute; SysUtils.FormatSettings.DecimalSeparator := FormatSettings.DecimalSeparator; This will give you option 2 if you don't change TCustomXMLXSDExporter.FormatSettings and option 1 if you do override the settings. IMHO the default should be that the system that creates the file can also open it. In cases 1 and 3, I might need to customize the decimal separator for float export. This means (as far as I have been able to find out) tweaking the Sysutils.Formatsettings... Right? yes In any event, I'll first try and see what newer versions of Access and ADO.NET do... As you have probably already figured out, ADO.NET XML and Access 2002 XML aren't compatible. Files created by one can't be read by the other. ADO.NET breaks on the schemaname and suggest http://www.w3.org/2001/XMLSchema . Access can't read the table schema and imports everything as text. Seems decimal separators are only a minor detail... Ludo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Timezone information in a dataset datetime field?
Hi all, I'm busy with writing an XML export unit targeting Microsoft Access/.Net framework (ADO.NET data access framework in particular). Runing an ADO.NET demo program I found out that the ADO.NET variant requires timezone info in its date/time fields. In a sample export I did, it is set to my timezone (UTC+2 at this moment). 1. Is there any way of knowing what kind of timezone a datetime value should be in a FPC dataset? (I suppose not...) 2. If not, I think I'm going to just use the current timezone. Is there any cross-platform way of doing this? In the docs, I just found GetLocalTimezone/TZSeconds in e.g. the linux unit... I could of course use the Windows API to get something similar on Windows, but what about OSX, or BSD or Solaris... Thanks, Reinier ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Timezone information in a dataset datetime field? - updated
Hi all,
I'm busy with writing an XML export unit targeting Microsoft Access/.Net
framework (ADO.NET data access framework in particular).
Runing an ADO.NET demo program I found out that the ADO.NET variant
requires timezone info in its date/time fields.
In a sample export I did, it is set to my timezone (UTC+2 at this moment).
1. Is there any way of knowing what kind of timezone a datetime value
should be in a FPC dataset? (I suppose not...)
2. If not, I think I'm going to just use the current timezone. Is there
any cross-platform way of doing this? In the docs, I just found
GetLocalTimezone/TZSeconds in e.g. the linux unit... I could of course
use the Windows API to get something similar on Windows, but what about
OSX, or BSD or Solaris...
I found some code thread How to get UTC time from 2007:
would that still be the best solution?
2a: Unix:
{$mode Delphi}
uses unix,sysutils,baseunix;
function utc_now : TDateTime;
var
timeval: TTimeVal;
timezone: PTimeZone;
a: Double;
begin
TimeZone := nil;
fpGetTimeOfDay (@TimeVal, TimeZone);
// Convert to milliseconds
a := (TimeVal.tv_sec * 1000.0) + (TimeVal.tv_usec / 1000.0);
Result := (a / MSecsPerDay) + UnixDateDelta;
end;
2b: Windows:
{$ifdef MSWINDOWS}
{ This uses SysUtils and Windows. }
function emt_now: TDateTime;
var
st: TSystemTime;
begin
GetSystemTime (st);
Result := SystemTimeToDateTime (st);
end;
{$endif}
Thanks,
Reinier
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] FPC for ARM-7
I am hoping to use FPC for ARM-7, compiling and debugging on a Windows machine. At the moment I am using Keil C + ULink2. Is it possible to use FPC from Windows and debug via the ULink2? Regards, Andreas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC for ARM-7
On 23-07-2011 20:34, Andreas Berger wrote: I am hoping to use FPC for ARM-7, compiling and debugging on a Windows machine. At the moment I am using Keil C + ULink2. Is it possible to use FPC from Windows and debug via the ULink2? I'm sure it should be possible. FPC can generate code for ARM7, and it seems it generates Stabs and DWARF for it too. I haven't tried debugging, so I don't know how well it works ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Download EmbWeb sources
I've tried again to use fppkg to download embweb and I guess I still need 2.5.1 or something for it to work. Can I download the embweb source and package independently? Looking around the svn I don't see embweb anywhere. Thanks, -- Warm Regards, Lee ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Download EmbWeb sources
On 7/23/2011 8:27 PM, Lee Jenkins wrote: I've tried again to use fppkg to download embweb and I guess I still need 2.5.1 or something for it to work. Can I download the embweb source and package independently? Looking around the svn I don't see embweb anywhere. I see there is a snapshot with 2.5.1. Trying that. Thanks, -- Warm Regards, Lee ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Download EmbWeb sources
On 7/23/2011 10:41 PM, Lee Jenkins wrote: On 7/23/2011 8:27 PM, Lee Jenkins wrote: I've tried again to use fppkg to download embweb and I guess I still need 2.5.1 or something for it to work. Can I download the embweb source and package independently? Looking around the svn I don't see embweb anywhere. I see there is a snapshot with 2.5.1. Trying that. Well, that doesn't work either. Actually, I get the exact same error that I got with lazarus snapshot 0.9.31.x and fpc 2.4.4: M:\lazarus_current\lazarus\fpc\2.5.1\bin\i386-win32fppkg install embweb The FPC Package tool encountered the following error: [embweb] Package fcl-web none is not available M:\lazarus_current\lazarus\fpc\2.5.1\bin\i386-win32fppkg list Name InstalledAvailable embweb -0.9.0-926 gecko-0.9.0-1504 jquery -0.9.0-842 lazmkunit-0.9.2-1 lnet -0.6.4-2534 webdesign-0.9.0-906 Thanks, -- Warm Regards, Lee ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
