dummzeuch

Actually I invested many hours to improve the performance of the formatter. But that was many years ago. I don't know how I found the time for that. Probably by not wasting so much time in front of the bloody TV...

13 minutes ago, Attila Kovacs said:

I know it! All the SQL queries go there. Nobody else needs this.

No, there are other kinds of strings where this could be usefull, e.g. JSON or CSV data for e.g. unit tests.

3 hours ago, luciano_f said:

 

I believe I found the solution

I activated several things in GExpert and now it is doing what I need, see

 

 

Hm, looks like I actually finished that work I was talking about, and had forgotten 😉

2 hours ago, luciano_f said:

 

I wanted to hide Delphi's "UniDac" menu, it has no use

 

 

 

That is not a menu of the IDE but one added by some plugin or possibly a property editor.

(Or it is part of a higher SKU than I know, e.g. Delphi Enterprise or Delphi Architect)

7 hours ago, luciano_f said:

This post is old. Is there anything in gexpert to remove items or move them from the Delphi mainmenu ?

There are only two options for now:

• Hide Window Menu
• Move the Component menu to Tools

Both can be found on the IDE tab of the GExperts configuration dialog.

I have no plans exending this functionality, but I am - as always - accepting patches.

@Attila Kovacs I had started some work in this direction (not just for TMenuBuilder but also some of the other tool windows that seem to open at random positions (Action Manager, Popup Menu Builder ...) but never finished it. If you have got some working code, I'd be willing to try including it into GExperts.

Best way would be to open a feature request on Sourceforge, attaching the code.

2 hours ago, Darian Miller said:

I don't buy that it is 'always the case'.  The way to avoid that is to develop the IDE support with the new language feature at the same time so they are released at the same time.  The IDE is obviously there to assist the user with the language - if the language outpaces the IDE, then the user cannot properly utilize the IDE.  It is a self-defeating scenario.  And when the IDE support is many years behind language features it also becomes a real credibility problem.  

You are missing the point. We are not talking about missing/incomplete/buggy IDE features here (or at least I am not) but the pain in the lower back any new language features poses for third party tools that parse the source code, in particular the GExperts sources formatter, where the code isn't really well structured.

9 hours ago, Uwe Raabe said:

@dummzeuch I haven't had a look at it for quite some time, but is the formatter free/open source or are there any restrictions to it?

It has been donated by its original author to the GExperts project, so it has the same license as GExperts itself. The source code is part of the GExperts sources, but lives in a subdirectory of its own with few dependencies to any outside code.

25 minutes ago, timfrost said:

Could you not just have an option to leave things the way they are, and still support Yukon?  For people like me, long time users of GExperts formatter, who find it an  absolutely essential tool and who will have no problem in resolving never to use a triple quote for its new purpose.

I wasn't talking about Yukon. I can live with the formatter not supporting multi line strings, if (!) it turns out the change is too complicated. But these not supported language features add up over time and once they reach a certain threshold it simply doesn't make much sense use the GExperts. In an ideal world I or somebody else would start implementing support for new language features during the beta phase. But I'm not participating in the Beta and of some other Beta tester has made those adaptions, I don't know about it (he wouldn't be allowed to tell me).

Btw. you could still use that feature, simply enclose those constructs in {(*} and {*)} so the formatter will leave that code alone.

1 hour ago, Uwe Raabe said:

If the parser is too complicated by itself, it probably doesn't matter which syntax change is actually chosen.

It definitely does.

1 hour ago, Sherlock said:

Surprisingly (or not), this argument leads to spending more time with legacy code over time than rewriting from scratch. At least that has been my observation for the past 20 years.

Yes, I know. But I also know that rewriting something from scratch takes a lot more time than one initially thinks. And may projects that start out as "This legacy code is cr*p, let's rewrite it" get cancelled due to time and budget overrun.

Since my time is severely limited, I'm not going to rewrite that parser as long as it kind of works. And if it terminally breaks, I'm going to remove the code formatter for newer Delphi versions instead. There is a built in code formatter in the IDE after all, even though I don't really like it.

Btw: I hope the built in code formatter was tested with multi line strings ...

1 hour ago, Uwe Raabe said:

I actually prefer the new syntax over the suggested one, as that is already occupied by a call to function multiline taking a string parameter - and fails because of the line-breaked string literal.

That "multiline(...)' example was just the first thing that came into my mind. I just wanted to show something easier to recognize than these three quotes.

1 hour ago, Uwe Raabe said:

This makes tweaking the parser not too complicated, as the start and end tokens are easy to recognize. 

Unfortunately the parser is quite complicated as it is now (I wouldn't have written it that way, but I also don't want to take the time to rewrite from scratch), so I wouldn't bet on the tweak being not too complicated. We'll see.

3 hours ago, emileverh said:

They heard my voice ;-))

 

https://blogs.embarcadero.com/yukon-beta-blog-delphi-language-modernizing-string-literals/

Not quite the implementation I would have liked though. Triple quotes '''? Who came up with that? Is that copyied from another programming language?

I mean, Pascal is said to be very verbous, so why not somehing more explicit like:

blub := multiline('
line1
   line2, indented
line3
');

People who don't like verbosity would complain of course, but these would complain about Pascal syntax anyway.

(Goes away, silently weeping and anticipating yet another long night trying to adapt the GExperts Source Formatter to yet another string syntax ...)

As with any website: Print it. On paper, if you want to add notes. To pdf and send it to your ebook reader, if you prefer that.

The only sure way I know to prevent windows from updating is to disconnect it from the internet. That can be easily done with a virtual machine. Alternatively it's probably possible to only block it from accessing Microsoft servers.

Of course there is the option to pause updates, but that only works for up to one month and has to be extended regulator after that. And it won't prevent an update to the next Windows 10 release when support runs out.

The easiest solution would probably be to assign different shortcut keys.

No idea which part of the IDE now uses them.

Did Embarcadero buy SmartInspect? When? Last time I looked, it belonged to Code Partners Pty. Ltd.

8 hours ago, Vincent Parrett said:

Which was is a PITA as it makes inc files just a tad more complicated than they would be otherwise. I usually have something like this so I can have one inc file that supports versions before and after XE4

  {$IF CompilerVersion > 24.0 } //XE4 or later
    {$LEGACYIFEND ON}
  {$IFEND}

 

Why not just use IFEND for all?

{$LEGACYIFEND ON} switches XE4+ back to the old behaviour. (Didn't know that, it never mattered to me, as I always had to support some older Delphi version anyway.)

2 hours ago, Anders Melander said:

So, can anyone remember which version of Delphi broke that scheme?

 

It's not broken now, but I'm certain that there was a version after Delphi 6 that somehow broke {$IF} so it couldn't be used if backward and forward compatibility was needed.

The only problem I remember is that early versions required {$ifend} rather than {$endif}. Apart from that checking the compilerversion should work for all versions after Delphi 6 (I cannot speak for Delphi 8 though, I skipped it).

3 hours ago, Tommi Prami said:

Can anyone figure out why Embarcadero could/would/should not publish rtl, compiler etc versions and codename for the beta, just as they include first outsider to the beta test?

 

Those things are not that big of an secret.

That would make it harder to detect breaches of the NDA and start arguments about where the limits are. It's much easier to forbid any mention.

10 hours ago, Anders Melander said:

It's been possible to do {$if CompilerVersion >= XX} since Delphi 6 or 7.

It was introduced with Delphi 6.

What is "Delphi 11.3 Alexandria, lite"? That does not sound like something Embarcadero offers.

2 hours ago, FPiette said:

That's right, but the number of installations is limited (I think it is 3). After that you have to contact Embarcadero to explain why you need more installations.

Or you get a network named user license, then you can have as many installations as you like. You can only use (run) a limited number of these installations at the same time, but I don't remember how many. It's more than two though.

I've got a tab on our About dialog that lists all open source libraries used in the project based on checking whether a specific unit is linked to the executable. The idea there is to automatically provide credits to these, but it could be extended to also include commercial libraries as well. Just find a unit name in these libraries that is always llinked in when the library is used.

It looks like this:

That's not quite an SBOM, but it is a good start, I think.

Of course this only makes is easier to get such a list if you have more than a few programs, otherwise doing it manually would not be such a chore either.

Here is the Stack Overflow question that got me started on how to do that:

https://stackoverflow.com/q/12104914/49925

Thanks for the suggestions. So far I like InstantGrep and LiveGrep best. InstantGrep might be better because LiveGrep in my opinion suggests that it also updates when the source code is changed or even when switching to a different tab, which at least currently is not the case and I am not sure I want to go that way.

Some other suggestions at least made me smile. Thanks for these too.