Dalija Prasnikar

7 minutes ago, Der schöne Günther said:

Are there more information available about the crashes themselves? 

 

And didn't Delphi get famous by demonstrating how an unhandled access violation would just produce a messagebox and continued to work afterwards instead of bringing the whole app down?

On Windows, yes. On other platforms not so much. Android and especially iOS are just sitting and waiting for opportunity to nuke your app.

1 hour ago, Sherlock said:

Well, as long as you didn't change your code, it's a strong hint towards deteriorating compiler quality (it could also be that iOS is getting worse, there seem to be some indicators towards that). Otherwise...well 😉

Not necessarily compiler, but RTL/FMX or other frameworks.

Yes, there were some changes in compiler that may have influence, but such errors tend to have impact across all platforms.

Now, it would be interesting to figure out what exactly is the problem.

Do you have any information about iOS versions used?

At some point (around version 11) iOS became more sensitive to touching UI from background threads. I had small test apps built with Tokyo and Rio that were happily running on iOS 9.x and were instantly killed on iOS 11.x.

3 hours ago, Kryvich said:

If VS is so great, then why RemObjects create Water - their own IDE for Windows?

1. Because they have full control and can do with it what suits their needs the best

2. Dogfooding

3. They also have IDE for Mac - Fire (and that was first one they wrote - AFAIK when they started that project there was no VS for Mac) - Water is just Windows variant to prove cross-platform viability of their approach

4. Here we were talking about VSCode that fits nicely for some things (not VS), but still is resource hungry Electron app. I don't know about Water, but Fire is native Mac application - which means fast.

5. When it comes to VS itself and VS being so nice... I don't know. Last time I used it it was dog slow comparing to Delphi IDE (around XE time).  

6. Having plugins for various IDEs can be nice and certainly is good place to start when you are just starting - but nothing beats fully dedicated IDE under your control.

I would suggest Git or Mercurial.

Mercurial is a bit easier to learn and most of the time prevents you from shooting yourself in the foot.  TortoiseHg works great and fast.

Git is more powerful, but has steeper learning curve  And I still have to find Windows Git client that actually works. On Mac SourceTree works fine, on Windows not so much - slow beyond description.

6 hours ago, Mike Torrettinni said:

I think I'm so reluctant to use classes, because I don't really have the typical need for them... all tutorials trying to explain the usage with basic examples of inheritance of TCar class and it's details... I just can't relate to anything I use. Except for encapsulation, but I already do this as shown in my 2nd example above, where everything is in record and it's unit. Not perfect, but the way I understand and know how to use it.

So, I'm not going to ask for good book or tutorial on classes, because they all contain such basic examples that I get lost in trying to relate to what I need... like everybody is either making control components or doing some kind of Car related projects.

@David Schwartz said it best: " I mean, you're going through a lot of gyrations simply to avoid using classes. " I guess I'm stuck in my world 🙂

Using classes just for the sake of using classes can be nice exercise in futility.

I have to admit that I haven't paid close attention to this post and I have been reading it rather superficially, so it is possible that I missed some piece. But from your original post I don't see any compelling reason why you should switch to classes. 

Especially if you don't feel comfortable with them and don't really see the point.  Main advantage of classes over records is polymorphism. If you don't have the use case for it, then records will do.

Also, one small note - you are holding your records in dynamic array, and those are allocated on the heap, not on stack. Only the few bytes of your global record holder would sit on stack. And overall, class based solution would use more memory than record based one.

That does not mean that you should not learn more about the classes, but trying to learn on wrong use case will make things harder not easier. You should learn about classes with examples where they really show their advantage and then you will be able to understand them better.

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. 

1 hour ago, Alexander Elagin said:

Have you seen the smile in my comment? I'd never use such design myself (for modal forms I use class functions, non-modal always have their own local variables). This was just an in-situ snippet to show how to use TFormClass and polymorphism in action based on the originally posted code.

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

4 hours ago, Alexander Elagin said:

Maybe something like this?

procedure AccessForm(var aForm: TForm; aClass: TFormClass; aModal: Boolean);
begin
  if not Assigned(aForm) then aForm := aClass.Create(Application);
  Assert(Assigned(aForm)); // just in case :-)
  if aModal then aForm.ShowModal else aForm.Show;
end;
.....
AccessForm(Form2, TForm2, True);
....

 

Just in case... What case? 

If construction of the form fails you will never hit Assert line anyway.

53 minutes ago, Ian Branch said:

I still think a switch to disable multiple copies to be open, or not, would be handy. 

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?

9 hours ago, Schokohase said:

That would imply that it is also usable from the day of available. But we learned that we had to wait for the first update ...

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.

2 hours ago, Rollo62 said:

I still have hope thats existing Apps might get  a somewhat less strict treatment. 

Its only a vague Hope...

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.

18 minutes ago, Steve Maughan said:

How to get access to quality.embarcadero.com?

 

My normal email and password that I use for the Maintenance site doesn't work.

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

2 hours ago, Rollo62 said:

Would be good to align the right launching strategy for new apps before the deadline.
For the earlier store changes I already placed new, planned apps, as dummy apps, before the deadline.
So that there are at least apps in the store, and Google might be a little less strict with them.

 

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"

2 hours ago, Sherlock said:

@Dalija Prasnikar:The context was "simple test programs". No regular users around those...I hope.

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

15 minutes ago, Der schöne Günther said:

But I don't understand - Isn't that just destructive? It throws away the additional information the default exception dialog would have shown you. It displays a generic message which is not helpful. A simple

doSomething()

is just better.

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. 

8 hours ago, Rudy Velthuis said:

Automatic invocation of the (parameterless) default constructor (and a copy constructor -- with one parameter of the same type as the record) is the whole point. All other constructors should still be called explicitly, just like in C++, so no need to turn things into class functions. There should only be one destructor, and that should also automatically be called. Actually, that is the most important thing about it. Even if the constructor were explicit, you would still want an automatically called destructor.

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. 

35 minutes ago, Rollo62 said:

There had been Rumors around that new MacMinis wouldnt be IntelBased, but Arm64.

Havent checked that recently, but if so it might cause issues with FMX in General.

I would check compatibility  before if I consider Mac Mini.

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.