Anders Melander

Not tested but I think you need to: Open DragDropDR103R.dpk (the run-time package) Save as DragDropDR104S.dpk Compile Open dclDragDropDR103R (the design-time package) Remove DragDropDR103R from requires and add DragDropDR104S instead. Save as dclDragDropDR104S Compile and Install. Personally I would just get rid of the run time package (and the requires).

That implementation is a bit over-engineered because it tries to handle mixing interface and object references. All you need to do reimplement _AddRef and _Release and stick to referencing the datamodule by the interface. Use TInterfacedObject as an example. There was a thread here earlier this week on that exact topic but apparently it was deleted or maybe got lost when the server went down.

Close enough.

You are just repeating what you wrote in your OP. It's really very simple. Just abandon your assumption that commands entered on the command prompt are treated the same way as commands in a batch file; They are not. The behavior you are observing is as expected. For console applications both cmd and bat will start the process, wait for its termination and set errorlevel to the process exit code. For GUI applications bat will do the same as for console applications, but cmd will start the process without waiting for it to terminate. The value of errorlevel is irrelevant. All this has nothing to do with Delphi BTW.

Strange question. Because batch file execution isn't the same as command line execution. There are different ways to start a process. The command line uses one method, the batch file another.

Yes. A GUI application will be detached from the console when it starts. For example if you type "notepad.exe" on the command line and press enter, notepad is started and the command prompt immediately returns. Even if your application sets ExitCode this is communicated back to the console because the console just launches the application and doesn't wait for it to terminate. This is the same reason that GUI applications can't (reliably) write to the console.

I see the same behavior in 10.3 and 10.4; Pressing F11 cycles focus: Designer -> OI -> Editor -> OI -> Designer etc. While this doesn't work like I would expect (to the point where I think it unusable) at least it's consistent. FWIW it's been like this since Delphi 4. From Delphi 1 to 3 you could toggle between OI and Designer with F11. The behavior changed when it became possible to dock the OI to the editor and I guess it changed again when the editor and designer merged. Good luck with that. There has been complaints about this behavior for as long as I can remember.

Why on earth are you using RegEx at all? Just use one of the many existing functions or bake your own: function ValidateChars(const Value, ValidChars: string): boolean; begin for var v in Value do begin var Valid: boolean := False; for var c in ValidChars do if (c = v) then begin Valid := True; break; end; if (not Valid) then Exit(False); end; Result := True; end; Also consider using character classes. See TCharHelper in the System.Character unit.

Hardly. Just press Enter instead or press F11 one more time.

Can you blame them?

For Delphi 10.4 The dialog is TEXCEPTIONNOTIFICATIONDLG in dbkdebugide270.* (bpl, de, fr, ja). The string is resourcestring 65448 in the same file. I don't know the name of the resourcestring since I don't have the .drc file. I can send you a translation project with all four languages if you like - Or I can just explain how to get them yourself. English: "Project %s raised exception class %s with message '%s'." German: "Im Projekt %s ist eine Exception der Klasse %s mit der Meldung '%s' aufgetreten." French: "Le projet %s a déclenché la classe d'exception %s avec le message '%s'." Japanese: "プロジェクト %s は例外クラス %s （メッセージ '%s'）を送出しました。" I was briefly tempted to replace the Japanese with something amusing 😈

I mostly agree; Tag is often the mark of poor workmanship. When used at design-time you have to assign magic numbers with "hidden meaning" and it can very easily become a nightmare to maintain. The same goes for the GroupIndex property. For run-time though I'm not that concerned with it as long as the use is very limited. Sometimes you just want to get on with the the task at hand and using a dictionary to associate a handful of controls to some context can seem like overkill. That said, use of Tag definitely goes against my primary rule of development: Don't be lazy

Versatility comes at a cost. You can use an external TDictionary<TButtonItem, WhatEver> if you need to associate additional data.

Use the TButtonItem.Data property instead - or TButtonItem.Action.Tag?

Sometimes it works, sometimes it doesn't. https://www.merriam-webster.com/dictionary/-ish But I agree that it's mostly broken. Sure. I don't know why we need both Search for Usages and Find References though. It seems to me that Find References is better integrated - and it isn't as broken 🙂

Like I said: It work-ish

Completely useless? It's not a new feature and it used to work-ish so it's probably just broken in 10.4. Maybe you can use "Find References" (Ctrl+Shift+Enter) instead. It also works sporadically in 10.3. I don't know about 10.4 though. Personally I always just do a Find In Files. Much more reliable. I guess once they have ironed out the worst LSP bugs Search for Usages and Find Reference can replace that.

There are plenty of them here. It would be interesting to hear a Yea or Nay from some. My understanding is that the only reason commercial component vendors ship run-time packages is to cater for users that build their applications with them - i.e. run-time linking. That is a separate problem with a very simple solution: It may not be typical but that is exactly the way to do it. By having the component source in the project path instead of the global path and by linking against the project's local copy of the dcu you avoid duplicate dcu and version conflicts. The project I'm working on right now has something like 20-30 different branches under active development. I change my active branch maybe twice that amount during the day. If I were to work by your model every time I changed the active branch I would need to recompile the close to 100 different design- and run-time packages related to this project, including 3rd party packages. What I do now is just change the branch and keep on trucking. And that's just on my local machine; I would need to do the same on all the build servers since apparently they have also been compiling and linking the wrong way all these years.

Hmm. Looking at that RegEx I just realized that I forgot to handle the asterisk parameter specifier in my own code. To fix replace all three occurrences of: while (Result[n].IsDigit) do Delete(Result, n, 1); with: if (Result[n] = '*') then Delete(Result, n, 1) else while (Result[n].IsDigit) do Delete(Result, n, 1);

Wise decision. They are fun to write but a nightmare to maintain.

I'm contesting the requirement to use run-time packages on the basis that I've written hundreds of components and I don't think I've ever had to use run time packages. There might have been cases where code was shared between different design-time packages, but that has apparently been so rare that I'm not sure if I remember it correctly. I can't find any documentation that backs your claim (if I've understood you correctly) that the component must go into a run-time package regardless if you use run-time packages or not. I agree that design-time editors (and component registration) go into design-time packages but unless you make the (often bad) choice to build your application with run-time packages there is no need to put the component into a run-time package. Who/what will use that package? The IDE will only use it because you've forced it to do so by creating a dependency from the design-time package to the run-time package. Yes, I expect the project to either have the pas or the dcu in the search path and I expect the compiler to static link to the dcu. The design-time package isn't bypassed. It's used by the IDE and only by the IDE - at design-time.

It depends on what I use the string for afterwards. For example if I need to compare with another string I just trim consecutive spaces down to a single. If I need to parse out the individual words I leave the spaces there since the parser will skip over them anyway. The function is for use in a translation tool. AFAIR it can also remove shortcut accelerators, () [] {} <> pairs and punctuation .:;? etc.

'%%'

You can find a function to strip out format specifiers (among other things), including the index, width and precision stuff, here: https://bitbucket.org/anders_melander/better-translation-manager/src/a9e47ac90e7f80b67176cdb61b72aa34f4a8f165/Source/amLocalization.Normalization.pas#lines-306 The code as-is replaces %... with space to make the result readable. This is the relevant code: Result := Value; // Find first format specifier n := PosEx('%', Result, 1); while (n > 0) and (n < Length(Result)) do begin Inc(n); if (Result[n] = '%') then begin // Escaped % - ignore Delete(Result, n, 1); end else if (IsAnsi(Result[n])) and (AnsiChar(Result[n]) in ['0'..'9', '-', '.', 'd', 'u', 'e', 'f', 'g', 'n', 'm', 'p', 's', 'x']) then begin Result[n-1] := ' '; // Replace %... with space // Remove chars until end of format specifier while (Result[n].IsDigit) do Delete(Result, n, 1); if (Result[n] = ':') then Delete(Result, n, 1); if (Result[n] = '-') then Delete(Result, n, 1); while (Result[n].IsDigit) do Delete(Result, n, 1); if (Result[n] = '.') then Delete(Result, n, 1); while (Result[n].IsDigit) do Delete(Result, n, 1); if (IsAnsi(Result[n])) and (AnsiChar(Result[n]) in ['d', 'u', 'e', 'f', 'g', 'n', 'm', 'p', 's', 'x']) then Delete(Result, n, 1) else begin // Not a format string - undo Result := Value; break; end; end else begin // Not a format string - undo Result := Value; break; end; // Find next format specifier n := PosEx('%', Result, n); end;

No one has mentioned run-time packages except you, so where does that requirement come from? Again I'm puzzled why you keep explaining these things. I'm pretty sure you must be aware that I know all this already. Besides that your explanation is wrong. The form will load just fine since the component unit has been linked directly into the application because it's not in a run-time package.