A Seattle Runaway
My colleague was just doing the normal edit, F9, break, edit, F9, etc – when this happened. The compiler went runaway and found a lot of errors! In fact, it didn’t run out of errors – but kept finding them until
he killed #10Seattle .
After a restart and a F9 – no errors and ran as expected.
Naturally, it is impossible to reproduce on demand.
Cosmic ray bit flipping? Random data in uninitialized buffers? Aliens?
The curse of the Project.res file
We’ve switched to #10Seattle for our production code, and we had a lot of “fun” figuring out why our FinalBuilder produced .exe files did not run, but stopped with “The application has failed to start because its side-by-side configuration is incorrect.” It turned out that FB8 used a default manifest from RS which looked looked like this
$(asmv3_application)
$(dependency)
$(trustInfo)
So – we tinkered with the settings and asked FB8 to load the manifest from the resource file. Nada. Zip. Zilch. It was not there. It turned out that you had to compile locally, then commit the .res file to make the manifest appear.
The Project.res files are always a bit of an annoyance, and we are perhaps a bit inconsequent how we resolve a conflict on SVN update – use local, or use theirs. This means that it is a bit iffy what actually survives in the .res file. In the end, we’ve ended up making individual .manifest.xml files for each app – and explicitly include it in the FinalBuilder configs. This means that if we make modifications to the manifest somehow, we need to upload that file separately.
The .res file conflicts are a worse problem than two people making changes to a .dfm – as the .dfm is text and can be resolved – while the .res file in binary and not human readable.
It really is beyond me why there is no Project.rc file which includes
Project.version.rc
Project.icon.rc
Project.themes.rc
Project.manifest.xml
and so forth.
That way, the .res file would be a compile-time thing (or even a thing of the past) – and the resource linker would assemble the various bits from their individual sources.
It would probably make it way easier for Finalbuilder to dig into the resources and/or override where needed and it would certainly make the VCS .res file conflicts a thing of the past.
A non-hidden directory+file .settings/settings.json appeared in one of my source directories. Is this a #10Seattle thing?
The hidden directory __autorecovery also showed up, but that was documented (http://docwiki.embarcadero.com/RADStudio/Seattle/en/AutoRecover).
I used TinyTake to record my #10Seattle toolbar weirdness.
Can anyone else reproduce this?
Windows 8.1, 1920×1200, Text size “smaller” (i.e. 100%?)
Problems with #10Seattle registration?
Did anybody else see any problems with the registration of their RAD Studio or Delphi installation?
I just discovered that it has registered my installation to a different email address than my EMBT registered one. It seems it has used my MS Outlook email address, which is the one that my Windows installation is linked with.
Does any of you see a “wrong” email address on Help|About?
Another #10Seattle Castalia weirdness that just happened, and I can’t reproduce 🙂 Structure blocks found in binary .dfm data 🙂
I’m actually having some Castalia weirdness all over the place. The structure highlighting is enabled, but sometimes it just doesn’t show up.
Transparency issues with #10Seattle ?
Update: Enabling Runtime Themes in Project Options, solves this issue.
I’m having some transparency weirdness issues which I find difficult to recreate in a SSCE. In the attached image, you can see a login dialog in design mode at upper left, and some of it’s properties at the right – and in the middle – the running dialog. You see those three white spaces that is not in design mode? That’s TLabels that fail to be transparent.
In the .dfm, the highlighted label looks like:
object lAppDetail: TLabel
Left = 33
Top = 82
Width = 54
Height = 14
Caption = ‘lAppDetail’
Font.Charset = DEFAULT_CHARSET
Font.Color = clInfoBk
Font.Height = -12
Font.Name = ‘Tahoma’
Font.Style = []
ParentFont = False
end
The labels are transparent when compiled with XE7.
Here comes the weird part: To make the label transparent again, I just uncheck and recheck the transparent property, which adds the transparent property.
object lAppDetail: TLabel
Left = 33
Top = 82
Width = 54
Height = 14
Caption = ‘lAppDetail’
Font.Charset = DEFAULT_CHARSET
Font.Color = clInfoBk
Font.Height = -12
Font.Name = ‘Tahoma’
Font.Style = []
ParentFont = False
Transparent = True
end
So – I try to recreate in an SCCE – I create a new form in XE7, add an image, add a label, set the same colors, etc. It’s transparent when running in XE7. I open the project in 10Seattle – and it is transparent when running there too! And there is no Transparent = True property in the .dfm.
Weird or what?
Refactoring: Change of type name does not change type for record helper. When using Ctrl-Shift-E to rename a type, a reference to the type in a record helper will not be affected. The expected behaviour is that the type is replaced in the record helper declaration as well. Problem verified for #10Seattle and XE7.1, but probably exists in XE8.x and versions prior to XE7 as well.
https://quality.embarcadero.com/browse/RSP-12384
You must be logged in to post a comment.