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-win32>fppkg install embweb The FPC Package tool encountered the following error: [embweb] Package fcl-web is not available M:\lazarus_current\lazarus\fpc\2.5.1\bin\i386-win32>fppkg 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
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
[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] 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] 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
[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] 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
: 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
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: 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 : [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 : [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 : [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
[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: 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 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
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
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
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
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
[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: >> 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