Dalija Prasnikar

VSCode is great tool. It has its downsides (being Electron app wasteful with resources) but I guess you can't have it all. It is far from being full fledged IDE for all purposes (and all languages), but it fits nicely into developer toolbox. As far as Delphi is concerned, it can fill some gaps in Delphi IDE functionality, and sometimes it comes as a rescue when Delphi bugs itself out. With OmniPascal plugin it will get you a long way in cases where code completion stops working in Delphi and there is a lot of code that is not RAD and does not include working with forms. I also like it for editing frame and form files, when I had to change something without Delphi IDE interfering. But the feature I like the most is its search capability with automatic preview of selected file so you can easily get more code context - no mouse clicks, just keyboard. I also sometimes use it to edit Java code (and xml layouts), when Android Studio has a bad day - which is quite often. Even more often I use it to write Swift code, because Xcode can be a huge PITA, too. Not to mention it has markdown preview - really handy when writing documentation.

Some people will just copy paste anything smile or no smile 😉

Just in case... What case? If construction of the form fails you will never hit Assert line anyway.

File feature request at Quality Portal an post the link back here. I know many that would find such switch handy.

Creating at run-time is pretty straightforward. You need Owner and Parent, and sometimes setting Align property. You can use any FMX control as those - or at least I have been able to use them without a problem. FFrame := TMyFrameClass.Create(AParent); FFrame.Parent := AParent; FFrame.Align := ... And that is it.

Eh... I completely forgot you can turn that off

.dsk file in your project root folder. It will open project in state you had when you closed it. If you had code view open, you will get code view, if you had design view you will get that. It also remembers last settings for each form. And first time it will show design view (at least that is the case for the last few versions).

Is Delphi Rio broken? NO.... Why does my Android application, compiled with Delphi Rio, no longer work?

Define usable. Yes, I am aware that different people will have different needs and not all bugs affect all people. And while there is a number of bugs that are still not resolved, I haven't encountered any really showstopper Android issues with Tokyo or Rio, regardless of the update number. What might be greater problem in this case is general direction of removing ARC http://blog.marcocantu.com/blog/2018-october-Delphi-ARC-directions.html that would most likely happen in 10.4 release (as hinted in a linked blog post). If that happens that would be major change that could introduce bugs in both Delphi frameworks and your application code. While in the most part cross-platform code is also meant to run on non-ARC platforms, there are parts of the code specific for Android and/or iOS platforms where people were counting and using ARC. In any case, I assume that there will be open beta for 10.4 version, just like there was for 10.3, and that developers on active subscription will be able to participate and ship applications with that beta if needed. I know this is far from ideal scenario, but it is better that nothing.

No, they will not have less strict treatment. Google knows exactly how many applications are affected by this (they can easily analyze applications submitted to the Play Store), and with the exception of older Unity games, obviously there is not too many. Also, vast majority of Android applications don't have to worry about CPU support because they don't use (link) CPU specific code (libraries) and are written by toolsets that emit Android Dalvik byte code.

AFAIK you have to use your username instead of email, unless your email is also your username.

Dummy apps will not help in this case. Updates also have 64 bit requirement. At this point in time it is hard to say what is the right strategy, beyond making sure that you finish and polish your apps as much you can before the deadline. 10.4 is scheduled for mid 2019 so all should be good, but you never know.

@Rollo62 @Kryvich {$RTTI} directive has local scope. That means you cannot set it for whole project and have it applied on everything. If you want to remove advanced RTTI from RTL/VCL, you have to recompile RTL/VCL, which is what OP wants. As far as recompiling Rio RTL/VCL is concerned, I haven't tried to do it... so I don't know what are the problems and even less what would be solution.

You can file report at Quality Portal When you create new issue select "Documentation Bug" under "Issue Type"

If I had a dime for every time some "simple test code" ended in production... 😋

I am sure your users will appreciate reading default exception message they cannot comprehend. Of course, "There was an error" is not proper error message - but that is different discussion topic.

Yes, of course. The only time you don't want destructor to run is when you didn't write one and your record does not contain any managed fields that need finalization.

This can be a number of things including certificates. From my experience, the fastest way to fix this is creating empty application in Xcode with same bundle ID and run it with debugging on the device through Xcode. Xcode will automatically resolve all the issues. After that, restart PAServer and run your Delphi app.

Just released Mac Mini 2018 versions are all Intel based. No worries for now. But 2018 versions are far from cheap. 2014 are better choice for FMX.

Any 2014 Mac Mini will do. You can even use older ones, but they will be obsolete sooner. Since, Apple just updated Minis with brand new line, older models are having action sales https://www.amazon.com/Apple-1-4GHz-Silver-MGEM2LL-Version/dp/B00746X7G2

Maybe this can help https://stackoverflow.com/questions/41469082/open-gl-shader-with-2-textures

You are right... implicit variable hell There were some issues with scoping... so I went to check with simplest example... too simple I am afraid...

type TFoo = class(TInterfacedObject) public constructor Create; destructor Destroy; override; end; constructor TFoo.Create; begin inherited Create; Writeln('Foo Create'); end; destructor TFoo.Destroy; begin Writeln('Foo Destroy'); inherited; end; procedure Test; begin Writeln('procedure begin'); Writeln('before inner scope begin'); begin Writeln('after inner scope begin'); var ref: IInterface := TFoo.Create; Writeln('before inner scope end'); end; Writeln('after inner scope end'); Writeln('something'); Writeln('procedure end'); end; Results with following output procedure begin before inner scope begin after inner scope begin Foo Create before inner scope end Foo Destroy after inner scope end something procedure end

procedure Test; begin Writeln('Test started'); begin var obj := Shared.Make(TTestObj.Create)(); Writeln('obj = ', obj.ClassName); end; Writeln('End of nested scope'); Writeln('Test completed'); end; Test with above code, please. I am testing with plain TInterfacedObject and it works as expected...

You are wrong... object is destroyed at the end of the inner scope... but your output 'End of nested scope' is still executed within inner scope.