luebbe

Does anyone have experience with the combination of this component with VCL styles? My first tests aren't very promising. It looks like I have to set every color of the component manually when a VCL style is applied.

... removes moss which was hidden under the corona haircut... I'm pretty sure that a friend of mine had alice pascal on the atari. Still got my Apple //e with the Z80 card. I wonder, if the CP/M disks still boot. Maybe they do, but I don't have a monitor for the Apple anymore.

Same n00b feeling here. Started with UCSD Pascal at the university and had Turbo Pascal on my Z80 in the 80s.

Check the permissions on Jenkins. Depending on the configuration your Jenkins runs as system or as a dedicated user, but not as "you". So it may not have access to some things.

If you want to increase the challenge, place your windows toolbar at the top. This screws up a lot of Delphi applications when maximized. Maybe only in combination with VCL styles.

Coming from CVS, SVN was a huge relief. I've contributed to TortoiseSVN quite a lot. At work we are using SVN or Mercurial, depending on the Team :D. For my OSS stuff im only using GitHub, even though I have accounts on SF, OSDN, GitLab and Bitbucket too. The workflows are different. Some things are easier with SVN others with Git. I like pull-requests a lot. They allow you to contribute to a project without having direct commit access. The equivalent in SVN would be sending patch files.

maybe @dummzeuch indended to tag @Remy Lebeau instead?

There's also the Virtaal translation editor, which hasn't been updated for a while, but works fine. There are many platforms that can handle gettext .po files and provide nice web editors, if you are in need of collaborative translation. Most of them are free for OSS projects.

Hi Folks, I've got two 24" monitors with different resolutions: 2560x1440 -> 122ppi 1920x1080 -> 92ppi Application is set to per-monitor-dpi-v2. Window's scaling is set to 125% on the WQHD monitor. If it is at 100%, the application doesn't get any dpi-change notifications. They should be called "windows scaling change notifications". 😏 When I move the application window between the monitors, there is a lot of flickering going on until all controls are redrawn. Depending on the number of controls, this can take a "while". Is there a way to avoid this visible flickering, in order to get a smoother transition between monitors? Just for laughs: switch your monitor scaling between 100% and 125% with the IDE window open... 😈

Thanks! I just used FixRSP30931.pas (https://quality.embarcadero.com/browse/RSP-30931) which you referenced in RtlVclFixes.pas. I guess I don't need the other fixes with 10.4.1. This cuts down the delay when moving from one monitor to the other by roughly 33%.

Kiriakos' suggestion works fine. The window is still unresponsive for a few seconds, but at least the flicker is gone.

That value was calculated from monitor size and resolution. The IDE is set to 96 and 96 is stored in the .dfm files. The (Before|After)MonitorDpiChanged methods report changes from 96<->120 dpi (scaling by 1,25).

Lovely! Thanks a lot! So I have to live with the delay, which is kind of ok, when there is no more flickering. Maybe I should show a popup "Rescaling form, please wait" 😉 Now I only have to cope with the numerous rounding errors, that make toolbar buttons and other controls shrink over time.

The joke is: There is a "SystemColors" checkbox, but obviously Emba decided not to call StyleServices.GetSystemColor(), so I had to turn it of and tried to adjust the titlebar colors manually. This works, sort of, but the windows border color is not the style's border color anymore. So this has to be set manually as well...

Thanks @Vincent Parrett. You are confirming my observations. So I won't invest any more time into this control.

@dummzeuch, With TortoiseSVN you could implement a local pre-commit hook that removes the Explicit properties from all or just the modified .dfm files. We do this to normalize .dproj files before commit.

I had blank Grep windows as well until I compiled GExperts with 10.4.1 and replaced the dll. Now everything seems to work as expected.

Yes, recompiling GExperts with 10.4.1 fixed the crash issue too. Might be interesting for @dummzeuch to know. So third party add-ons compiled with an earlier version of Delphi cause trouble in 10.4.1. What about the other way round?

Maybe compiling with 10.4.1 has fixed the issue? I'll update my GExperts sources and build the dll. Let's see if it works afterwards.

It's hidden functionality, which is not intuitive. I had to explain it to every colleague, so you probably only saw the tip of the iceberg. You already change the hint, once tests are selected. Why don't you also change the Icon accordingly to indicate that the functionality has changed? I can try to design an icon that fits in with the others.

No, it wasn't reported on the TI issue tracker. I only stumbled across it this morning after installing TI 1.1.8.0 in 10.4.1.

The docking issue with TestInsight has been fixed in TestInsight 1.1.9.0. Kudos to @Stefan Glienke See:

They might be following this thread already. 😉 Considering the fact that only the IDE has changed and that the same third pardy add-ons didn't cause exceptions in 10.4.0, it may also be the case that the add-ons uncover problems of the IDE.

See my previous post: - Docking "pure" IDE windows, save/restore desktop works - Docking third party windows, save/restore desktop fails

Not properly saving/restoring window positions on a secondary monitor is clearly to blame on the IDE. This has never worked correctly (for me) since I got a secondary monitor (first tried with 10.1/10.2). When I dock more IDE child windows on the secondary monitor, everything is fine. Save and restore works (apart from the coordinates). Something goes wrong when the coordinates of third party add-ons are saved (tried with TestInsight, GExperts Grep). - If the windows are undocked, the coordinates aren't saved at all. The windows disappear as soon as the desktop is restored. - If the windows are docked, an A/V occurs when the desktop is restored. I guess the A/V when restoring a docked child window is to blame on the combination IDE (TestInsight|Grep), because one of them tries to apply VCL Styles to the (TestInsight|Grep) window and fails.