I try with your suggested pattern format but it does not work either. Same
EConvertError with different error message.
I guess, I have to parse it manually
Zamrony P. Juhara
https://v3.juhara.com
https://github.com/zamronypj
Fano Framework
https://fanoframework.github.io
mod_pascal
"Note that to include any of the above characters literally in the result
string, they must be enclosed in double quotes."
This only makes sense for FormatDateTime which returns a string you can display.
For example:
writeln(FormatDateTime(' "" = ', now));
To print:
= 2020
--
No it does not work. Docs says literal string needs to be quoted with "
Zamrony P. Juhara
On Wed, Apr 29, 2020 at 9:37, Alexander Grotewohl wrote:
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
Can't test, but from the docs shouldn't it be something like:
adateTime := ScanDateTime(
'ddd, dd mmm hh:mm:ss GMT',
'Wed, 29 Apr 2020 10:35:50 GMT');
--
Alexander Grotewohl
https://dcclost.com
From: fpc-pascal on behalf of Zamrony
P. Juhara via
Hi,
How do I convert string with HTTP date format such as
Wed, 29 Apr 2020 10:35:50 GMT
back to its TDateTime value?
I try with ScanDateTime()
adateTime := ScanDateTime( 'ddd", "dd" "mmm" "" "hh:mm:ss" GMT"',
'Wed, 29 Apr 2020 10:35:50 GMT');
but EConvertError exception is raised with
On Tue, 28 Apr 2020 20:58:18 +0700
Ryan Joseph via fpc-pascal wrote:
> > On Apr 28, 2020, at 8:52 PM, Mattias Gaertner via fpc-pascal
> > wrote:
> >
> > Codetoolboss.Error*
>
> Not sure I'm understand the usage. When do I check for errors and are
> there ever more than 1 or just the last
> On Apr 28, 2020, at 8:52 PM, Mattias Gaertner via fpc-pascal
> wrote:
>
> Codetoolboss.Error*
Not sure I'm understand the usage. When do I check for errors and are there
ever more than 1 or just the last error? I'm guessing maybe after:
URI := ParseURI(textDocument.uri);
Code :=
On Tue, 28 Apr 2020 20:28:16 +0700
Ryan Joseph via fpc-pascal wrote:
>[...]
> Speaking of that is there a way in code tools to get a list of
> parsing errors that occurred for a given file? It's possible that
> parsing fails but I don't know where errors occurred until I make a
> query and comes
> On Apr 28, 2020, at 7:47 PM, Michael Van Canneyt
> wrote:
>
> Incredibly looking forward to test-driving this in Atom... :-)
The biggest left is getting diagnostics working so we can see errors that popup.
Speaking of that is there a way in code tools to get a list of parsing errors
On Tue, 28 Apr 2020, Ryan Joseph via fpc-pascal wrote:
On Apr 28, 2020, at 4:04 PM, Michael Van Canneyt wrote:
You can do what most VSCode/Atom project managers seem to, add package.json
or somesuch:
{
"pascal-lsp" : {
"projectfile" : "yourproject.pas",
"searchpath" : ["a","b"]
> On Apr 28, 2020, at 4:04 PM, Michael Van Canneyt
> wrote:
>
> You can do what most VSCode/Atom project managers seem to, add package.json
> or somesuch:
>
> {
> "pascal-lsp" : {
>"projectfile" : "yourproject.pas",
>"searchpath" : ["a","b"]
> }
> }
Yes, that's what the plugin
On Tue, 28 Apr 2020, Ryan Joseph via fpc-pascal wrote:
On Apr 28, 2020, at 3:45 PM, Michael Van Canneyt wrote:
Why do you think so ? The codetools will find all referenced units that it
finds in the unit search path.
You're right. I was thinking there are going to be units that aren't
> On Apr 28, 2020, at 3:45 PM, Michael Van Canneyt
> wrote:
>
> Why do you think so ? The codetools will find all referenced units that it
> finds in the unit search path.
You're right. I was thinking there are going to be units that aren't referenced
by the main program but why do
On Tue, 28 Apr 2020 15:34:57 +0700
Ryan Joseph via fpc-pascal wrote:
> > On Apr 28, 2020, at 3:26 PM, Michael Van Canneyt
> > wrote:
> >
> > That's a wrong approach. Pascal units are in a uses-tree. You need
> > a starting point, the top of the tree: a single module.
>
> I can make the user
On Tue, 28 Apr 2020, Ryan Joseph via fpc-pascal wrote:
On Apr 28, 2020, at 3:26 PM, Michael Van Canneyt wrote:
That's a wrong approach. Pascal units are in a uses-tree. You need a starting
point, the top of the tree: a single module.
I can make the user provide the program file and
> On Apr 28, 2020, at 3:26 PM, Michael Van Canneyt
> wrote:
>
> That's a wrong approach. Pascal units are in a uses-tree. You need a starting
> point, the top of the tree: a single module.
I can make the user provide the program file and start from there but then the
references in other
On Tue, 28 Apr 2020, Ryan Joseph via fpc-pascal wrote:
On Apr 28, 2020, at 3:06 PM, Mattias Gaertner via fpc-pascal
wrote:
You can add any number of files as start. Just call AddStartUnit
for every starting module.
For example add all Pascal modules of the workspace directory.
In
> On Apr 28, 2020, at 3:06 PM, Mattias Gaertner via fpc-pascal
> wrote:
>
> You can add any number of files as start. Just call AddStartUnit
> for every starting module.
> For example add all Pascal modules of the workspace directory.
In TCodeToolsOptions we provide FPCOptions and ProjectDir
On Tue, 28 Apr 2020, Mattias Gaertner via fpc-pascal wrote:
On Tue, 28 Apr 2020 09:34:36 +0700
Ryan Joseph via fpc-pascal wrote:
> On Apr 28, 2020, at 4:18 AM, Mattias Gaertner via fpc-pascal
> wrote:
[...]
LSP doesn't have a concept of the "main file" but this seems to
require the main
On Tue, 28 Apr 2020 09:34:36 +0700
Ryan Joseph via fpc-pascal wrote:
> > On Apr 28, 2020, at 4:18 AM, Mattias Gaertner via fpc-pascal
> > wrote:
>[...]
> LSP doesn't have a concept of the "main file" but this seems to
> require the main program file to start the search from. All we get
> from
20 matches
Mail list logo
