Leaderboard

In an earlier thread I presented an Interface-based access to native Windows (Direct2D) SVG support for Delphi applications. This has now been integrated into the SVGIconImageList components by @Carlo Barazzetta. Carlo is a kind of master of ImageLists (among other things). Have a look at his IconFontsImageList for instance. His SVGIconImageList component was based on the work of Martin Walter who must be a great programmer. His SVG component covered almost every SVG element and was well structured and cleanly written. There were numerous bugs and issues though, which, to a large extent, were fixed over the last few weeks and the code was refactored and optimized. Finally, @Vincent Parrett contributed a virtual version of the Image List, mirroring Delphi's VirtualImageList. So in its current form the component features: An SVGImageCollection component that inherits from Delphi's CustomImageCollection and thus is compatible with VirtualImageList A choice of SVG engines: the pascal one based on Martin's work which is using GDI+ and the native Windows one which is using Direct2D. Other SVG engines can be plugged-in with minimum effort. Excellent design support with a nice and effective SVGImageCollection editor developed by Carlo and the built-in VirtualImageList editor. Support for changing the opacity and color of the SVGs including using GrayScale. If you adopt Material Design for example and you use VCL styles, you can adjust the icon color to the style. Compatibility with older Delphi versions going back to XE6. It is free and open-source Svgs are vastly superior to bitmaps because they are typically tiny text files and scale perfectly. So, you do not need to ship with your application multiple resolutions of your images to match the DPI of the monitors. And there is a vast number of free SVGs to cover most needs. IMHO the combination of SVGImageCollection with Delphi's VirtualImageList is the best available solution (commercial ones included) for building DPI-aware Windows applications. Give it a try.

I want to personally thank Vincent Parrett and Kyriakos Vlahos for the great contribution to the project! The official 2.0 version will be released shortly and also published on GetIt. Meanwhile, you can download the project from Github and report any problems. I'm also working on IconFontsImageList to add similar funcionalities, like a IconFontsVirtualImageList and IconFontsImageCollection...

Well, I found solution. It was my bad. I had FDConnection.Params.OpenMode = omCreateUTF8 So changing it to omReadWrite rather is a solution.

Hi, You didn't specify the path. assests\internal is for deployment TPath.GetDocumentsPath, 'db.s3db' is for PATH br, M

This gets a bit off topic and while I have no problem answering here. It is really probably better answered at the VMware communities Fusion forum (I read every post at the Fusion and Workstation subforums, but you can always ping me there too ) Not that I am the expert on the graphics stack, but I might be able to help, if only to get the right information for others to help you. There's a lot of factors that can influence this, like your VM's configuration, what hardware you are running (not all MBP's are the same) and what version of VMware Fusion you are running. If you have an MBP then you probably have 2 graphics adapters (discrete and integrated) and you can tell VMware which one to use as a probably mitigation. I don't have your problem, nor have I seen it myself. MSPaint 3D works fine here, not that I ever use it. Earlier versions of VMware Fusion would use an openGL renderer at the host, while nowadays a Metal renderer is used. Older graphics cards work better with the openGL backend and newer ones with the Metal one. You can switch the background renderer if your MBP is older (like a MBP from 2014 or earlier) and it helps. Then there's the whole matter of which 3D technology you're using. As you are in a Windows VM, DirectX is currently limited to DX10 and openGL to version 3.3. (VMware Fusion 12/ WS 16, to be released in a few weeks go to DX11 and OpenGL 4.1) The DX compatibility level also depends on the virtual hardware version you choose. While things might be choppy on a slower configuration, none of it should ever crash the host. As you can see I need more info to investigate your issue...

Animation is not simple, I can only imagine the amount of work required to implement animation - and that's not really the intended direction for SVGIconImageList - as you can tell from the name of the library, it's about using svg with imagelists.

Keep all The Query components in data-module, if you keep FDconnection and Query or table in another form this error gives, i had the same issue. so then i kept all tables in side Data-module , its work fine.

It is in records/seconds so the higher the better. And it includes the ORM layer - which is very low in practice. You can see for instance that if you use TDataSet (and DB.pas depending units) then reading one record/object has a noticeable overhead, in respect to direct DB access, as ZDBC does or our direct SynDB classes. For a reference documentation, with some old numbers, you may check https://synopse.info/files/html/Synopse mORMot Framework SAD 1.18.html#TITL_59 Edit: you will see that the ORM also supports MongoDB as backend. Pretty unique.

This breaks at times, has for different releases depending on code and debugging for a long time.

Meanwhile the necessary TChart files have been "published" via some download link in the QP report RSP-28780.

https://www.google.com/search?q=free+resource+editor+res http://melander.dk/reseditor (I'm the author)

The work on https://github.com/EtheaDev/SVGIconImageList continues, many issues have been solved. Now it's possible also to use native VirtualImageList (from 10.3 or 10.4) linked to a TSVGIconImageCollection! If you have an older Delphi version you can use TSVGIconsVirtualImageList. With the help of VincentParrent and pyscripter the components and the SVG library improve day by day ... Stay tuned!