Dalija Prasnikar

3 hours ago, eivindbakkestuen said:

Are you sure that option does not exist anymore? 🙂 I'm pretty sure I didn't dream this up.

 

LOL... I missed that. I guess I am accustomed to uninstalling first, then cleaning up left overs before installing, so I haven't seen that dialog for a long time.

It is quite possible that this option somehow got broken, after introduction of Migration Tool and unifying installers (Web and ISO) in the 10.4. Please, file bug report. Otherwise it will stay broken forever.

33 minutes ago, M.Joos said:

I just ran the migration tool and wanted to transfer my settings from 10.3 to 10.4. Now at startup of 10.4 I get a "Index out of bounds error" with succesive "Interface not supported" errors. The Ide does not start any more. Does anybody have any ideas? Is there a way to undo the migration ?

TIA

 

You can use RegEdit to remove registry key HKEY_CURRENT_USER\Software\Embarcadero\BDS\21.0

Deleting (or renaming) that key will remove all custom settings.

If possible it would be good to determine source of your problem. Do you have any IDE plugins installed in 10.3 or other 3rd party components - packages (including your own). Maybe imported settings are trying to load something incompatible. 

I just tried to import my settings from 10.3 again in 10.4 and everything works fine for me.

2 hours ago, eivindbakkestuen said:

No, you didn't miss anything, exact same thing happened to me. I'm absolutely certain I had Help checked during the first install, because this also happened to me during 10.3.

 

Worse part of it was, even though I'm absolutely sure I left the "remove registry entries" option in the "keep" position during uninstall, after the reinstall the IDE came up pristine, and left me with installing a ton of 3rd party libraries a second time. Ugh.

Err... that option does not exist any more. You have to use migration tool to preserve settings if you are reinstalling and updating and also for upgrading to new major version.

1 minute ago, aehimself said:

By mistake I already discovered this option and disabled it. It shows as off in Dephi IDE and ToggleTheme in Registry values stores 0. Still, color values in Editor \ Highlight \ * are being reset to the values of the scheme selected.

This might be a bug, then. I just found one similar to what you are describing 

IDE does not remember user color seting for source editor

https://quality.embarcadero.com/browse/RSP-28754

2 minutes ago, aehimself said:

So I started to experiment with Delphi 10.4. When we switched to 10.3, I immediately installed the VS code color theme (https://blog.grijjy.com/2017/12/29/alternative-dark-editor-themes-for-delphi-10-2-2/) via the Migration Tool as I think it's the most eye-friendly scheme - plus I got used to it already.

My issue is that Delphi 10.4 simply does not want to accept this. I tried to manually update the values in Registry but as soon as the IDE restarts they are being overwritten. Does anyone know where Delphi 10.4 stores the saved color schemes? I would try to create a new one and set it as a default for my dark theme; I just don't know where to put them 🙂

There is new option in Options -> User Interface -> Theme Manager called Toggle style to match Windows Light and Dark mode. It is checked by default and that setting overrides any other custom settings. You need to uncheck that option before you can use custom theme settings.

If you want to edit registry directly under Theme key, this new option is called ToggleTheme (DWORD) and its value should be set to 0

There is a bug. You cannot move active tab. You need to select some other tab first and then you can drag the tab you want.

Cannot rearrange editor tabs, when it is selected

https://quality.embarcadero.com/browse/RSP-28465

14 hours ago, JeffBurroughs said:

Using latest 3.07.7 omnithreadlibrary download.

You already fixed the issue, but that issue is already fixed in Omni Thread, too. 

There is newer version in the making, not released yet, but it has fixes and packages for 10.4. Last commit was just 4 days ago.

https://github.com/gabr42/OmniThreadLibrary

When new Delphi release comes out and you find issues with some of the libraries you are using, it is good to recheck library for updates. Keep in mind that libraries cannot be publicly updated before official release and sometimes takes a few days to have those patches and fixes generally available.

10 hours ago, pyscripter said:

Minimalist implementation of SmartPointers based on a old post by Barry Kelly  comparable to the Spring4D one in performance.

It is simpler, but not faster.

FWIW, I am using the same simple implementation because I don't need that extra speed. Smart pointer already brings in some performance drop and in places where I can live with that I can also live with unoptimized version of smart pointer. But if you really want to use smart pointers and you really need every last CPU cycle you can squeeze out of it, then Spring4D is the way to go. 

46 minutes ago, Angus Robertson said:

For the past 20 years, I've installed Delphi in my own named root directories, never program files, but just realised that I was never offered a choice of install directories while installing 10.4 from the ISO, or if I was, missed it on some cluttered screen.  So it now seems to be buried in program files...

You missed it... look for Options button in the bottom panel (on the left of Next, Cancel... ) I am not sure whether it shows in first or second screen... but it is there.

This one is rather important fix - it is fixed for both LSP and Classic Code Insight

Code completion does not work inside anonymous methods

https://quality.embarcadero.com/browse/RSP-23252

https://dalijap.blogspot.com/2020/03/unified-memory-management-coming-with.html

Yes, 10.4 will have unified memory management on all platforms.

I have created GitHub repository with code examples from my book Delphi Memory Management for Classic and ARC Compilers.

It is still work in progress (there is plenty of code) and currently, it contains examples from Part 1 and Part 5. The rest is coming...

https://github.com/dalijap/code-delphi-mm

1 hour ago, Der schöne Günther said:

The person who handled the billing received the last email from Embarcadero in summer 2019. Maybe because we paid for the Update Subscription for several years in advance, it's different? I don't know.

 

The 10.4 beta sounds promising - Is there something like an email address where I could ask what is going wrong here? I received beta invitations a few years ago. I remember XE6, and I think XE8.

This is not official advice... 

I would try contacting sales, or support https://www.embarcadero.com/support or some of Embarcadero Product Managers like  @Marco Cantu

It is important to note that anyone with active update subscription can participate in Beta https://community.idera.com/developer-tools/b/blog/posts/get-ready-for-the-10-4-beta-with-update-subscription

1 hour ago, Bill Meyer said:

I think you will find that it is not a change in policy, but that they have been given permission to write about the coming release, which is likely to appear rather soon.

You are right about permission part.

2 hours ago, Rollo62 said:

I hope this is ending the long, long favorized age of "SORRY, I can't say anything, because of RadStudio Beta NDA will kill me and eat my soul".

"Sorry, I can't say anything, because of RadStudio Beta NDA will kill me and eat my soul" is still valid for everything else.

8 minutes ago, Lars Fosdal said:

I've also seen compile time issues where you must specify the type T of the iterator for a TArray<T>.  

I cannot say I had such encounters. In every place I tried to use them, main problem was killing code completion and navigation (or maintaining backward compatibility)

I also used them (actually, type inference that comes along) in some places where my old library code was no longer compilable in Rio - mostly around changes in generic lists and Items. 

On 3/14/2020 at 8:56 AM, Lars Fosdal said:

Have anyone done an article on the current pitfalls of inline variables?

There have been few bugs around inline variables, but for using inline variables in day to day code, probably the greatest problem was non functional code completion and code navigation. They would also break Error Insight, but that thing is all kinds of broken, so having one more way to break it is not critical. Besides, Error Insight itself is not critical feature.

On the other hand, one permanent pitfall lies in inline variables combined with type inference and reference counted classes as explained in my blog post https://dalijap.blogspot.com/2019/03/inline-variables-type-inference-and.html

There is complete list of iOS devices at https://en.wikipedia.org/wiki/List_of_iOS_devices

iPhone 5 and iPhone 5C are 32bit, while iPhone 5S is 64bit. 

Anything having 6 in name is 64bit, Just check whish OS version is the latest version particular device supports. iOS11 and newer only support 64bit devices.

Official numbers can be found on https://developer.apple.com/support/app-store/ but they only show stats for devices released in last four years. 

As far as whether you need to support 32bit applications or not, that is hard to say... depends on your audience (kids can still play games on ancient iPads and don't care about how old that thing is). But most likely 32bit can be safely ignored. 

On 4/17/2020 at 5:24 PM, Rollo62 said:

How about a better error-detection by the compiler/linker, would that be thinkable ?

Couldn't be all the do's and dont's in the compiler logic (as switchable error option of coarse, for those who need it as is) ?

Probably that not possible either, but maybe the most common, drastic mistakes/misuses could be turned into some clear compile time errors (warnings).

There is nothing compiler can do here. Compiler does not have intrinsic knowledge how particular class implements reference counting and therefore cannot emit warnings in proper places because it does not know whether particular piece of code is correct or not.

1 hour ago, Rollo62 said:

Would be maybe a good time and place to make some clear proposals howto improve interfaces, instead of moaning all the time.

So how exactly should they get fixed, so that all can be happy ?

Full ARC compiler on all platforms and getting rid of TComponent ownership model would be the only proper solution. But that would definitely not make everyone happy.

Maybe additional "interfaces" as abstraction that is not tied with memory management could solve most of the issues, but I never given that too much thought in terms of finding potential gotchas and additional levels of complexity such feature might add.

19 minutes ago, David Heffernan said:

Is it unreasonable to expect that programmers have knowledge and skill?

No,, but learning takes time.

I am not talking here about lazy people that don't want to learn, I am talking about efficiency of learning a language that has additional levels of complexity comparing to learning language that doesn't and where both languages are generally suitable for solving some problem. I know that knowledge accumulates over time, so you will not have to relearn things you know the next time around, but such things do have overall impact on productivity.

32 minutes ago, Sherlock said:

Oh, come on. That is not really an issue, it's just a No-No. Just like not changing some Label on a form from a thread without synchronizing. Just don't do it, and you will not get into trouble.

Yes, it is an issue.

Even if you ignore "just don't do it" part which you first have to know exists and then have to learn how to do properly in Delphi (not so easy as in Java, C# or other languages where you can use interfaces easily), main problem is that you cannot just have some IFoo interface and implement it on every class you like and use it equally. As long as all implementing classes handle ARC the same way, it is fine, but try having IFoo on TInterfacedObject descendant and TComponent descendant and you are basically screwed (or at least seriously limited in what you can do with such classes).

1 hour ago, Jacek Laskowski said:

But try this "trick" on TComponent or it's descendants... no way.

Which is exactly one of the issues mentioned in article. 

Interface should be an abstraction that is always handled the same way, but implementation details of the particular class will leak and in some cases you will need to know how implementing class handles memory management. And then whole abstraction castle will just collapse.

Yes, interfaces in Delphi are troublesome.

From perspective of being tool for achieving abstractions they are commonly more trouble then they are worth. Chad explains some issues well. 

If they are used as COM interoperability, then there is nothing wrong with the because that was exactly their original purpose.

If you are looking on them as tool that can give you automatic memory management they are great, because you can more easily solve some otherwise complex problems that would require complex solutions. However, their use in such cases is limited and you cannot use them for such purpose everywhere. For instance you cannot add ARC to visual frameworks that are build on top of TComponent ownership model and automatically handle lifetime of your visual controls.

Main problem with interfaces is not that they are badly done per-se, but that they add duality to Delphi memory management and as such additional complexity and care is needed when you are using them. That is one of the reasons why I liked mobile ARC compiler. It showed that without that duality interfaces and objects can live happily ever after and that you don't have to look around your shoulder every time you use interfaces, expecting that they will kick you in behind.

Of course, full ARC brought other issues, but those were related to using existing frameworks that were not written with ARC in mind, so we got that dreadful DisposeOf...

No matter how you look at it, Delphi memory management is complex, sometimes too much... it is not question of being able to learn about things, but about how easy and how fast can you write your code, focusing on task at hand without needing to fiddle with all nuisances of handling your objects lifetime. 

No caveats for above code. You can freely Free object instance from different thread than one where it is created.  

Problem would arise if you would have object instance that is being simultaneously accessed by multiple threads.