Davide Angeli

Now I'm switching to Skia (but using HTML Components too).

In the past I've used this one that is also very good: https://www.bverhue.nl/delphisvg/

and this one (with some limitations): http://www.riversoftavg.com/svg.htm

2 hours ago, Vincent Parrett said:

Why is this too complicated for people?

Summurized in few words like Anders do it seems not really complicated. I will try it.

3 hours ago, Vincent Parrett said:

Pull requests make a lot more sense for open source projects,

I think you are right. In the specific case, the problem seems that there is no one who pulls the strings, so the risk is having dozens of pull requests that will never be integrated.

3 hours ago, Vincent Parrett said:

1) create an issue and discuss with the other contributors/owners - then when everyone is on the same page

It is diffcult to do when you have the perception that no contributors has time to dedicate like in this case...

On 7/15/2022 at 7:11 PM, dummzeuch said:

I'm not an active JEDI  member either. I stopped contributing - as little as I did - when they switched do Github. Not sure how many active people are left in that project.

I never used Github to contribute but it seems not so immediate to use... I want to create a pull request to post a couple of corrections on a jcl unit but I don't understand if I have to fork the project and then create the pull request from fork or if I could directly create a new branch on my local master and push it in same way (I m using SmartGit on local git repositories)...

uhm... ok good to hear that issue tracker is abandoned... so issues would be better to post directly on github.

JCL seems quite static also on github. Just an example, till last year I was using JclSysInfo to get Windows version and it was very quick on updates but now at all there is no Win 2022 server recognition so I switched on standard Delphi functions.

Hi all! 

I have always been using JCL/JVCL libraries in my Win32/64 VCL applications.

Is anyone still keeping them alive? I opened some reports in the JEDI Issue tracker (also posting the possible solutions) but with desolation I see that in the last few months there are only new error reports and no one taking them in charge. 

IMHO it is always the same of this:  https://en.delphipraxis.net/topic/4628-several-f2084-internal-error-on-delphi-1042/

It's not a D11.1 problem. This kind of problems (f2084 internal errors, av in dc32xxx.dll, ecc )  were introduced (or emphasized) at least in D10.4 if not in previuos versions.

I'm now using 11.1 too and fighting with these issues every days. There are several reports on QC but they never solved the problem. 

In my case these problems increase exponentially working on a big project group containing several BPLs, DLLs and EXEs (all VCL), when I compile one of the BPLs that are used (statically or dynamically) by the other projects. In these scenario the crash is almost at every compile. Closing the IDE and restarting all works fine.

16 minutes ago, Vandrovnik said:

In 64bit app, pointer is 64 bit - if PrinterInfo is a pointer, it should be casted to NativeUInt or something like that...

Infact I solved in that way. The legacy code is not mine. That project use old libraries just 64bit compiled. One is Rave library (the sample is about it) and the other is Fibplus that has also old hard casts on pointers not always considering 64 bit pointers.

Hi all, I had some trouble in the last days after updating from D11 to D11.1 and I want to share if could help some one (maybe someone already wrote about this). 

In a 64bit VCL program I'm using legacy code that before 11.1 worked without errors. In D11.1 Emb introduces new Windows PE security flags in linker options and in particular a couple of them related to ASLR (https://blog.marcocantu.com/blog/rad111_pe_security.html). These flags are enabled by default and in my case, on legacy code (bad written), leads to random access violations. For "bad" code I mean do hard cast on pointers for instance something like this: "pointer(integer(PrinterInfo) + SizeOf(TPrinterInfo4));". Disabling the new ASLR linker flags the win64 app works but I guess that should be better to refactor that kind of code.

23 hours ago, ULIK said:

Davide,

 

it's just a vague guess: you use a dark color scheme on IDE. Do you see the same problems also when using the light default scheme?

14 hours ago, Lars Fosdal said:

It is often possible to reduce the problem to a small example - it just that it is sooo much work - and hey, we don't work in EMBT QA.
Edit: ... or do we?

You are completely right. I have done this successfully several times. As you say the problem is finding the time to devote considering that the problem occurs in a completely random way. 

I could see that I'm not the only one... some one already reported these unresolved annoying problems also on 11.1:

https://quality.embarcadero.com/browse/RSP-37648

as you can read on the report this guy is available to remote debugging to solve the problem (it is not the only one...). I did same last year with 10.4.2 but no one contacts me so after 11.0 and 11.1 we're still here begging for some help.

Wow this one seems new (another access violation in dcc32280.dll) and just changing the active project double clicking on the treelist in the project pane:

I'm using D11.1 in the last two days. This kind of problems seems not solved:

The error is now more beautiful to see colorful but it always remains unsolved ...

It happens always working on a large projects compiling and debugging the pieces (DLLs, EXE, BPLs.. ) and swicthing from a project to another. I guess it is totally useless to open a new report in QC as it would be closed for the umpteenth time as "cannot reproduce".

After the first exception, madexcept shows always this call stack trying to close IDE (note that on 10.4.2 e 11.0 was pratically the same). I don't know if could be useful...

4 hours ago, KenR said:

10.4.2 crashes several times a day on large projects for me. I have not yet been brave enough to try them in 11.1

for me too... Some months ago I've updated to 11.0 hoping in a better life but crashes are exactly same of 10.4.2. In the next days, maybe tomorrow, I'll give a chance to 11.1. I hope it won't be worse than it is now. I am now used to restarting the IDE at least once every 10/15 minutes.

3 hours ago, FreeDelphiPascal said:

And of course.... closed.

Closed... I hope... solved in 11.1 ?

I've dozens of this errors a day with 11.0 (not updated yet to 11.1) and they are exactly the same errors of 10.4.2.

Hi all, on my D11 Alexandria installation is not longer available the file brc32.exe in the bin folder (https://docwiki.embarcadero.com/RADStudio/Sydney/en/BRC32.EXE,_the_Resource_Shell).

On 10.4 the file is available. Is this utility no longer supported? I could not find any info.

We have been using this one from several years: https://www.certum.eu/en/code-signing-certificates/

They give us an usb token containing the certificate. To apply the certificate to our exe, dll, bpl, installers etc I've created a small custom internal delphi tool using this library: SecureBlackBox, its not cheap but we are using it for other digital sign purposes and it works fine interacting with tokens and certificates.

15 hours ago, Remy Lebeau said:

Hard to say for sure without seeing the complete FTP sessions, but if I had to guess, the command connection in TIdFTP is likely being dropped part-way through the transfer, which would explain why the final response is not being received, and also why sending a QUIT request after the transfer timeout is causing a RST packet.  Are you performing these transfers through a router/proxy/firewall, by chance?  If so, they tend to drop idle connections after a few minutes, and thus are likely dropping the command connection during a large transfer since the command connection is sitting idle while the transfer is in progress.  TIdFTP has a NATKeepAlive property to help avoid that issue, try enabling and configuring it as needed.

Thanks you just put me on the right path! IdFTP.NATKeepAlive property was already set in my application but probably with wrong parameters, maybe an IntervalMS too long. I've recalibrated the parameters (IdleTimeMS = 30000 and IntervalMS = 10000) and now it seems working properly (no read time out anymore).

15 hours ago, Remy Lebeau said:

You should filter the logs to isolate just the FTP command connections before saving them.  You don't need 500Mb to show a handful of packets.

Sorry I'm not a "Wireshark guru" it's the second time for me using it! I've to say that is not so easy to use. I've found how to isolate FTP commands directed to the FTP server IP address but even if the size has reduced, 100 mb still remains. Perhaps it can be reduced more but it is not necessary.

On 6/4/2021 at 5:19 PM, Remy Lebeau said:

I don't know what to tell you, then.  TIdFTP is not receiving a final STOR response from the server.  Since your FTP connection is not encrypted, have you tried using a packet sniffer like Wireshark to verify the response is actually being sent on the wire?

I've monitored with WireShark both Filezilla and TIdFTP transfer. I've attached the final part of the transfer of both. I did these tests one after the other. I really don't know why this is happening. I've done a test with Total Commander too and also with this tool there are non timeout problems. Why TIdFTP doesn't receive the answser and waits for a timeout? I could not attach the 2 wireshark log here because they are about 500Mb (but if it could be usefull I could upload it somewhere).

14 hours ago, Remy Lebeau said:

In your log, I don't see a final response being received from the server for the STOR command, or the QUIT command.  That would explain the timeout.  Are you able to perform a similar transfer using another FTP client, like Filezilla, and get a final response after the transfer is finished?

Hi Remy, I've just simulate that transfer with Filezilla (3.52.2) and it works fine (no timeout error)...

Just retried TIdFTP and unfortunatly with it the timeout is still present (I was hoping it might be a temporary internet connection problem but it doesn't seem to be the case).

Attached is the filezilla log if could help. In it I could see a message "226 transfer complete" after the send data. This message is missing in IdFTP log...

filezillatransfer.log

Hi,

I'm using TIdFTP to transfer a 100Mb file on a FTP server on cloud. This process always worked fine.

Now I've upgraded to D10.4.2 (I'm using INDY distribute with Delphi). I don't know what is changed now (if something on Delphi, on Indy or something on the FTP server) but now at the end of the file transfer, in the TIdFTP.FinalizeDataOperation the program raises an EIdReadTimeout executing this instruction:

...

GetResponse([226, 225, 250]);

...

The file seems transferred regularly. There is only something wrong in the finalizing operation. Attached there is the log file produced with TIdLogFile.

There is something that I could do or that I could check to avoid this timeout?

Thanks 

Davide

installa.exe.log

On 5/22/2021 at 5:18 PM, TurboMagic said:

Thanks!
Will check this. Do you know which consequences unticking that checkbox has?

I think is something related to use with c++. For me is irrelevant because I'm using only Delphi Pascal Compiler.

In my case I've solved unchecking the "Dual Packages" option in the 64 bit page

Same problem here... I just download latest JCL from github to upgrade it.

Win32 goes fine but when the installer starts to compile win64 I got this:

Could it be related to latest hotfixes? 

16 hours ago, mvanrijnen said:

At the moment here it's like the LSP/Codecompletion etc, is dependant on the weather or something, can not get my finger at it, when it stops. sometimes it works all day, today, it stops every 5 minutes working.

(especially, codecompletion and jump to things in other units)

 

Same here. Yesterday LSP/Codecompletion doesn't work the whole morning (close/reopen ide multiple times, rebuild every library etc but nothing) then I closed a couple of source files in the IDE's editor and it start to work again! 

Another amenity of yesterday, debugging a 64bit delphi application the IDE consumed all my PC memory (8Gb on 16Gb used by the ide alone!). This obviously crashed the whole system making debugging impossible. Closed the IDE and redone the operation everything worked regularly. They are not insurmountable problems but they are very annoying because they are continuous.