Leaderboard

Apparently it’s delayed due to high res dpi issues. It’s good that Embarcadero is having to develop it and discover the problems others have encountered with high res dpi. We might get some fixes as a result.

Delphi 11 Update 1 will support Firebird 4.

Ditto. At least they could tell us when and if it's expected so I could stop checking.

It never ceases to amaze me how people in these forums can have such deep and intimate knowledge of the code of the IDE and it's plugins and libraries that they feel they have the right to highly criticize the hard-working team behind the complex and powerful development tools we use. As an independent programmer, I can set my own deadlines--and I don't release anything until I'm sure it's ready. When I worked for a large corporation, executives that have to please shareholders are the ones that set deadlines--and whatever code was ready, was released. I'm sure the Delphi team would've loved to postpone the release of D11 until it was more fully tested and all the plugins were finished to be released along with them but I'm also fairly certain they didn't have a choice and are also not allowed to voice those internal issues. Personally, I feel sorry for them and the pressure they must be under, especially when they read these posts and can't do a single thing about it.

https://docwiki.embarcadero.com/Status/en/FireDAC_Database_Support Delphi 11 supports: v 1.5 - 3.0

Ok, at DelphiCon2021 David Millington answered that the bookmarks are coming soon, besides the HDPI issue they are working how it will be integrated in the IDE (whatever that means).

I don't know if this is the right place. Sorry in advance if I did a mistake. - Delphi 10.4.1 - GExperts 1.3.18 - Always when close appear an error similar "Error in expert 18". It is favorites file - After this error, Delphi never closes and a lot of AV comes from hell 🙂 - Tried to disable the expert with no success - I have never used this expert - I removed from DPR of the last SVN commit all the uses about favorites and recompile - No more errors

Right, I know this doesn't solve your issue directly. I thought of virtualizing your own Delphi app on the remote system, that maybe remotes Word locally somehow, but only you know what you need exaclty.

Finally they have to eat their own can of worms...

Maybe Cybele Software is also interesting, if you look for a solution with Delphi.

Microsoft Remote Desktop Services RemoteApp does this, so does VMware ThinApp Virtual Applications. This has nothing to do with Delphi and would probably break some Microsoft license somewhere.

Absolutely nothing to do with Delphi. Where does it fit? Google javascript remote desktop client. Then again, could as well use buildin mstsc client...

https://en.wikipedia.org/wiki/Law_of_triviality

The ZIP file headers are parsed and stored when you call Open. So I don't think this should be especially slow. However, it is wasteful to call FileNames repeatedly because it is a property with a getter method that makes a new dynamic array every time you access it. So I'd do it like this var zip := TZipFile.Create; try zip.Open(fZipFilename, zmRead); for var fileName in zip.FileNames do Memo1.Lines.Add(fileName); finally zip.Free; end; (not sure if the inline var inside the for declaration works, but if not you know what to do!) Although actually in this case you could simply write var zip := TZipFile.Create; try zip.Open(fZipFilename, zmRead); Memo1.Lines.AddStrings(zip.FileNames); finally zip.Free; end;

TZipFile.Filenames creates the result array each time on the fly. Caching that in a local variable should speed it up a bit. As an alternative you can use an array iterator: for var filename in zip.FileNames do begin vZipContents.Add(fileName); end;

You could easily debug and optimize this code. Calling zip.FileNames in the loop is very unhealthy as it will construct the list for every iteration. var lFileNames: TArray<string>; begin var vZipContents := TStringList.Create; var Zip := TZipFile.Create; try if TZipFile.IsValid(fZipfileName) then begin Zip.Open(fZipfileName, zmRead); lFileNames := Zip.FileNames; for var I := Low(lFileNames) to High(lFileNames) do begin vZipContents.Add(lFileNames[I]); end; Memo1.Lines := vZipContents; end; finally Zip.Free; vZipContents.Free; end; end; *(Edit: of course in this code there is no benefit to use vZipContents it would be better to use Memo1.Lines.BeginUpdate and Memo1.Lines.EndUpdate and insert the file names directly to the memo.)

Dave, Thank You very much for your help, it works. 🙂 I wish you all the best. Levente

Thanks for not sharing how you solved it?

I was mainly referring to the Delphi IDE, which only runs under Windows. The other stuff from Embt doesn't interest me. They can't deliver a stable IDE in Windows; I certainly don't trust that their cross-platform tools are any better. Not hitching my wagon to them. No thanks! Personally, I'm far more interested in using something like TMS WebCore for cross-platform development than native tools at this point, mainly because I've been watching how slowly Delphi as been getting updated and the inevitable bugs that show up after any major changes. TMS is way more responsive, and javascript seems to be far more stable running in all web browsers than trying to keep up with every update of mobile operating environments. Yes, it might be a bit more limited, but I'd rather invest in a more stable and consistent UX/UI than constantly dealing with what Delphi's native platforms offer. There was a point in my life where I *LOVED* working with beta copies of software and chasing down weird issues, but not any longer. I want to just get in, get something done, and move on. I guess I have come to value getting stuff out of my head as fast as possible without having to take a bunch of detours to deal with potholes in the road. My memory is getting flakey, I have trouble remembering names of things, and each of those detours takes me longer to regain focus when I get back to where I was.

Exactly. It's pretty pointless to suggest different ways of doing conversion if the conversion will be done with TryStrToFloat, StrToFloat or the like. And it's even more pointless when this is in all likelihood premature optimization.

Should this support any number format which TryStrToFloat supports? E.g. '5.4E7', '543,543.647' or ' $0abc6'? Or are there restrictions? What about decimal and thousands separators? What about negative numbers? Negative exponents? The more flexible it must be, the slower it will become. The easiest case would be: Only decimal digits and only a decimal point, no negative numbers. No range restrictions. No exponents. That would be fairly simple and fast, because it's a state machine with only a few states.

Have a look at the routines in SVGIconImageList/SVGCommon.pas at master · EtheaDev/SVGIconImageList (github.com) (GetExtended in the implementation section). They were "stolen" from synopse/mORMot: Synopse mORMot ORM/SOA/MVC framework (github.com) and they did make a big difference when parsing SVG files.

Possibly loop a pointer through the string, until and non-digit or non-comma is found, and no more than 1 comma's, maybe that could be faster. If the string ends without any break, it should be convertible string ( if the length is also somewhat limited to what maximum digits could be there ). But I haven't checked yet (too late) what TryStrToFloat is doing, maybe its already there. If I assume that most digits are in normal range (not above min/max limits), then this precheck to find non-digits could be faster, as a kind of pre-selection. But when you finally convert, you will have to consider the min/max again, to make it complete.

If your app is not able to handle new datatypes introduced in Firebird 4, you can use DataTypeCompatibility = 3.0 in firebird.conf You can also typecast the result of the multiplication to something you can handle.

I agree with that. Now, without going into whether Embarcadero is currently giving stable updates or not at the end of the line... In reality stability is possible only on Windows and Linux platforms because those platforms are stable enough. And even on Windows there will be issues in releases when major Windows version changes or some larger feature is introduced. Not all such compatibility issues can be easily backported without making breaking interface changes. On Android, iOS and macOS situation is completely different. New major OS versions are released on yearly basis, breaking havoc in both backward compatibility and ability to run applications on new OS versions. Often even building applications with new tools required will be broken. Porting back is often mission impossible. Delphi IDE is highly integrated environment and you cannot just easily swap and update only some parts that are broken. For those fast moving platforms only viable option is moving forward, having active subscription and participating in beta testing when it is publicly available. Or using other toolsets if Delphi does not fit well for certain use cases.