EtheaDev / SVGIconImageList

Three engines to render SVG (Delphi Image32, Skia4Delphi, Direct2D wrapper) and four components to simplify use of SVG images (resize, fixedcolor, grayscale...)
Apache License 2.0
327 stars 96 forks source link

missing support for XE2 #256

Open mcsmark opened 1 year ago

mcsmark commented 1 year ago

this is a great project. i read that even for D7 there is support? Or maybe i misunderstood. It could be still the goal. I see that XE3 is supported but my most recent license is for XE2. Is it possible to add support for XE2?

carloBarazzetta commented 1 year ago

Support starts from XE3, because I haven't installed XE2 to check if it compiles... Try it yourself using XE3 packages... Initially, this project uses TSVG library which was not compatible with Delphi7, but now it uses Image32 as default engine for rendering SVG and this library supports Delphi7... I should try and recompile it with Delphi7, but haven't tried yet...

mcsmark commented 1 year ago

thanks for your work on this and your reply. Of course i tried with XE2. But there are many errors. Some are fixable by rewriting code. But many errors remain. When it would work on D2007 is would be a miracle super since it would extend some of my apps a great deal. I hope you get some inspiration some day to get that done. Well you pulled this off too so nothing is impossible i guess,

carloBarazzetta commented 1 year ago

Actually you can use a similar technology with older Delphi versions: IconFontsImageList: https://github.com/EtheaDev/IconFontsImageList

mcsmark commented 1 year ago

i would prefer a virtual image/icon list but i will check the font solution. i do not like to install new 'fonts' but when it solves the problem it would be ok too. I had some problems getting the image32 to install into D2007. mainly since there is no Tpngimage but TpngObject which also worked. so at least i can load svg images now.

mcsmark commented 1 year ago

i installed and tested the iconfonts. but this is not for me. i already have svg files. i guess i am too acquainted with image lists. i wonder if i am the only one that want this? maybe i am the last on earth with D2007 :-) anyway thanks. the svg image already helps.

carloBarazzetta commented 1 year ago

Sorry but I've not plan to add support for XE2.

mcsmark commented 1 year ago

that is a pity. but it is the way it is.

the-Arioch commented 6 months ago

maybe i am the last on earth with D2007 :-) anyway thanks

Well, i do mantain a D2007-based legacy system :-)

That is how i ended there, i googled for my XMLLite wrapper thinking maybe to back-port it to D2007, and to make iDispatch wrapper to it, but in the end decided it was not worth it. It was funny to learn somebody actually did use that wrapper :-D

That said, if the project does not use the curser "record helpers" then backporting from XE3 to XE2 should not be hard. I used to do it for few months with VTV while i still worked with XE2.

mcsmark commented 6 months ago

haha, no you are not the last that uses D2007. It still produces great code for windows 10 and win11. I am sure there are lot of D2007 users but i understand it is not simple otherwise someone had done it. I tried hard to get the XE3 code to compile on XE2 but i am simply not capable enough to get it done. So i would be very happy if someone could do it. i port some projects to XE2. I only have a license for XE2. (and all the older delphis) Borland/codegear/embarcadero keep making updates which need a lot of $ to update. While my opinion was that it is a shame for what are essential updates which do not even fix all bugs. Anyway, nice to see another D2007 user:-)

carloBarazzetta commented 6 months ago

I'm sorry but I don't have the XE2 Delphi version, but if you can port this project to this platform you can make a pull request...

the-Arioch commented 6 months ago

Hello. I am not using XE2 today, so, no. If I'd did then I would :) Frankly, I dislike post-XE2 direction Delphi took, though that is off topic.

D2007 has a damn lot of bugs in VCL, ADO, compiler and it's debugger works very poor under Win10. One could expect being the last before umicode/generics it should've be polished fine, but it was not.

mcsmark commented 6 months ago

D2007 has some nasty debugger bugs. but XE2 does not seem that bad. well maybe i can do something more simple. I read that you now need a support account just to install XE2 another time on a new PC? which is outrageous. i do not like illegal stuff especial when i have a license but when codegear does illegal so can i by using XE3. it probably does not work that way but when my XE2 does not install on my next PC i will simply use XE3 which solves the problem too.

the-Arioch commented 6 months ago

need a support account just to install XE2 another time on a new PC?

Well, yeah, legalese of EMBA is one sad joke. Remember how they tried to prohibit all the work with non-local data in XE3 Pro beta-EULA? Not even asking if internet server exists. They retracted later, but the audacity...

All in all it seems post XE2 they only care about active payers. You do not pay yearly - you do not exist for them.

At my previous job (with a share of turf war between departments) we had a bunch of accounts, each with different set of versions activated timely. It did not help that different resellers and different upgrade purchases were used, too. So when I tried to match reg-codes I collected around the office with purchases I knew about even the total quantity did not match.

So, when i finally pushed through for consolidation we made a Grand Unified E-mail address to transfer all corporate licenses to, and we mailed EMBA to look for our domain in their records and transfer all them to that new address. I trusted them to tell us our purchase history, just wanted to make it orderly, for everyone.

Their reply was surprising. They said, that since they sold as "named licenses" it is not allowed to consolidate them to one e-mail, as that somehow would mean single person is using them all (like, several persons can not user a shared e-mail, illegal for sure). And that we must make sure real person names are recorded in their database (like, personal information laws? Whatever). And, since none of our EDN accounts have active support license they would neither update their databases (until we purchase Support year to every acc) nor even tell us whay and how many EDN accounts of ours they have (so, we should allegedly purchase support to unknown contracts?).

That was really funny. Not sure named licenses to corporate entities are even legally binding here. Anyway, we did inform them (not timely, I admit) about names changed (developers do resign, afterall), their database is not our responsibility.