Fritzew

For me this is a clear statement😀

Simple answer NO. The IDE Fix pack fixes only the IDE

No i think that is not the reason, dalija has the right answer i think

- About the IDE, on Windows I use the VS Integration most of the time, because on my machine it is open always. On Mac I'm using there Fire IDE and I like it. It is different but really fast. - Native CPU is fast but I have not done any profiling. To be honest if you look what the net runtime is doing, there is not more any reason to discuss "native" versus "CPU". But if you have more Questions let start a new thread, because we are now really off topic here

Yeah you can compile to NET, Mono, Java, Mac, Windows, Linux, IOS, Webcore. The Extensions to the Pascal-Language are really impressive. And you can mix Pascal, C#, Java, Swift in the same project. I'm at moment working with it a lot. (Porting a NET library to Mac). It is Amazing, the integrated Test Tools are great. Not to say there is MAC 64 Support....... But the best (for me) look at this declaration of a interface and implementing class: type testInterface = public interface property Name : String; end; testClass = class(testInterface) property Name: String; end; This is amazing.......

One of the best explanations I ever read..... Thanks for write this.

The best one in my opinion for Delphi: CAD VCL

Simply call [TYourClass].ClassInfo somewhere in the application or in the initialization of the implementing Unit. Should be enough

for me: C:\Program Files (x86)\ModelMakerTools\ModelMaker\11.11.0\bin

Yes ist must be the last unit, but the real problem is the IDE not finding the correct Unit....... We should not need a third-party tool for these kind of functionality. It should be work out of the Box, that's the reason for a IDE!!!

You are right, this is not possible, and the main problem in these case is the IDE and OTA. Should work independent from the themes

If it is the distance you are looking for, I don't think presorting are really faster as calculate the distance direct. from my experience presorting is in the most cases slower. But it depends. If the Data is more or less static then maybe presorting will win. in other cases Use Hypot to calculate the distance. for point in Pointlist do begin dist := Hypot(checkx-point.x, checky-point.y); if dist < checkdist then ..... end; Hypot is very fast You can also use a parallel Loop in this case

finale it is now possible to debug High-DPI problems in Rio, you can have two settings for the same program one with and one without a HighDpi Manifest. These makes it really easy to debug... Thanks Embarcadero, for me this is one of the best news about Rio!

Disabling this two options helps, but only after close and restart Rio

Works well now, compiled for XE7, Tokio and Rio

This is from Xe7: exception message : Assertion fehlgeschlagen (D:\Komps\Gexperts\externalsource\UniSynEdit\SynTextDrawer.pas, Zeile 469). main thread ($b60): 1394d934 +00 GExpertsRSXE7.dll 5005f108 +08 rtl210.bpl System 15885 +1 TObject.Free 50060a1a +3e rtl210.bpl System 22260 +17 FinalizeUnits 5985b984 +54 madExcept_.bpl madExcept InterceptFinalizeUnits 5985b98c +00 madExcept_.bpl madExcept InterceptHalt0FinalizeUnits 50061094 +ac rtl210.bpl System 23640 +82 @Halt0 7778fba0 +80 ntdll.dll LdrUnloadDll 76a41f70 +10 KERNELBASE.dll FreeLibrary 5005f108 +08 rtl210.bpl System 15885 +1 TObject.Free 2063a341 +19 coreide210.bpl ExptMain 210 +3 TExpertServices.Destroy 5005f108 +08 rtl210.bpl System 15885 +1 TObject.Free 5070bc1d +31 vcl210.bpl Vcl.Forms 3758 +3 TCustomForm.DoDestroy 5070ba52 +52 vcl210.bpl Vcl.Forms 3722 +23 TCustomForm.Destroy 210f57bb +3b designide210.bpl DeskForm 842 +8 TDesktopForm.Destroy 5005f108 +08 rtl210.bpl System 15885 +1 TObject.Free 5016bf93 +57 rtl210.bpl System.Classes 15390 +9 TComponent.DestroyComponents 50709541 +35 vcl210.bpl Vcl.Forms 2167 +9 DoneApplication 5008f8a9 +21 rtl210.bpl System.SysUtils 5768 +6 DoExitProc 50061052 +6a rtl210.bpl System 23602 +44 @Halt0 74718482 +22 KERNEL32.DLL BaseThreadInitThunk

Yes, there is something with Synedit...... But not every time I will compile it with Madexcept enabled, maybe I will see more

Can you tell us why you think these is right? There is no reason for this construct. Length(s) is enough .

Good Question, i have not seen any changes there. To be honest I was not aware of the GitHub fork. For my needs there was all there in sourceforge

I have checked my Source, it is from Sourceforge http://svn.code.sf.net/p/graphics32/code/trunk I have done 2 Steps to compile it for Tokio 1. Copy of package Dir XE8 do Tokio 2. in the GR32_Compiler.inc added: {$IFDEF VER320} {$DEFINE COMPILERXE8} {$IFNDEF BCB} {$DEFINE DELPHIXE8} {$ELSE} {$DEFINE BCBXE8} {$ENDIF} {$ENDIF} Compile the two Packages GR32_Rxxxx and GR32_Dxxxx Done

You know the difference between the logical operators? use or not and........ b := b and 1 00000000 b := b and 2 00000000 b := b or 1 00000001 b := b or 2 00000011 b := b or 8 00001011 b := b or 64 01001011

I think we are living in different times...... 😉

After Years of using MMX, learning something new today....... Thanks

This is something I'm also really missing.

If you are using TBCDField you can simply use Currency, because these Fieldtype is designed to work with currency as the internal DataType. Look in the Source from Data.DB.......