Anders Melander

Wrong conclusion. What is more likely? That there is something wrong with transactions or that there is something wrong with what you're doing? Your method is flawed unless you can guarantee that there will never be more than one transaction active against the database at a time. Consider this: A: Start transaction A: select max(NUMBER) returns 1 B: Start transaction A: Post new row with NUMBER=2 A: Commit B: select max(NUMBER) returns [...drumroll..] 1 B: Post new row with NUMBER=2 B: Commit Like Hans suggested, use a generator. That's what they're there for.

I think you would do everybody a favor if these plugins were completely disassociated from the core product and from Embarcadero. As it is now, being marketed as "official plugins", people expect them to be of a certain quality and to be delivered on schedule with the core product and there's obviously no resources to make that happen. If they were just "some dudes hobby project" then people would know what to expect.

Doesn't the debugger work for you? Just place a breakpoint in the Validate event handler and examine (using Evaluate->Inspect) the properties of the controls in question. It should be easy to see which properties contains the values you need.

If only there were someone at Embarcadero specifically tasked with communicating with the customers...🤔 Maybe @Jim McKeeth knows someone who can tell us what the hell is going on?

SourceTree is made by Atlassian. Any time you spend reporting bugs to them would better spent picking your nose.

Now there are 🙂 Do something like this: uses Horizon.IntegrationTest.API; // Via TApplicationEvents component: procedure TMainForm.ApplicationEventsActionExecute(Action: TBasicAction; var Handled: Boolean); begin {$ifdef DEBUG} TranslationManagerIntegration.TrackControl(Action); {$endif DEBUG} end; // Via the global TScreen instance: procedure TMainForm.OnActiveControlChange(Sender: TObject); begin {$ifdef DEBUG} TranslationManagerIntegration.TrackControl(Screen.ActiveControl); {$endif DEBUG} end; procedure TMainForm.OnActiveFormChange(Sender: TObject); begin {$ifdef DEBUG} TranslationManagerIntegration.TrackForm(Screen.ActiveCustomForm); {$endif DEBUG} end; Note: Remove the DEVEXPRESS define in Horizon.IntegrationTest.API if you're not using that library. As you can see the above only uses the integration in DEBUG builds but since I'm just using WM_COPYDATA for communication it's pretty harmless if the integration is also active in RELEASE builds.

Uploaded a new build: v1.3.8100.37233. I have finally managed to get upload to BitBucket working so it's available here now: https://bitbucket.org/anders_melander/better-translation-manager/downloads/ Changes since build 1.3.8055.21506: HighDPI scaling has been disabled in order to work around scaling problems caused by the DevExpress skinning engine. When these get resolved I will enable Per Monitor v2 scaling. https://bitbucket.org/anders_melander/better-translation-manager/issues/26/handle-highdpi-scaling @Renate Schaaf Automatically show and focus the multi-line editor if the source text contains multiple lines (optional, enabled by default). https://bitbucket.org/anders_melander/better-translation-manager/issues/15/auto-open-text-editor-when-applicable @aehimself Added a translation integration API which allows the application being translated to control BTM. Using this integration, when a form or control is focused in the application, then the corresponding module and property is selected in BTM. The integration API is contained in the file amLocalization.Integration.Tracker.API.pas Properties that have been omitted from the form resource, for example because their current values equals the default value, can now be synthesized so they can be translated. This solves the problem where for example TField.DisplayLabel could not be translated if DisplayLabel and FieldName contained the same value. A lot of minor bug fixed and improvements. See commit log: https://bitbucket.org/anders_melander/better-translation-manager/commits/

https://supportcenter.devexpress.com/ticket/details/t1073008

That's the same problem as the one mentioned a few messages earlier:

Didn't you read the documentation? Oh, wait... 🙂 I think there's a change request to have the editor shown automatically if the source text contains carriage returns.

I'm not sure what you're asking. Do you mean like this:

It's also the perfect place to get a noncommittal answer. I'll give you the answer right now so you don't have to wait: Okay, maybe not that last part but that would at least have meaning.

No such luck. I've reproduced the problem but it seems to be caused by a bug in DevExpress. I'll have a closer look at it tonight.

Thanks for the feedback. Keep it coming! I have not done any high DPI testing whatsoever but I'll see if I can squeeze that in today. Since I'm using DevExpress control it should mainly be a case of providing the correct manifest settings. - I hope 🙂 The long string problem has already been fixed in commit 6d52cf4438139b3c79c4776d444d85610782a5fc (26 jan 2022) but I haven't uploaded a build of that version.

Ah, yes; That's madExcept messing things up for everybody else. I thought you meant that madExcept didn't handle nested exceptions.

Works for me. What's your problem? type EInner = class(Exception); EOuter = class(Exception); ... begin try raise EInner.Create('Inner'); except Exception.RaiseOuterException(EOuter.Create('Outer')); end; end;

What property? 🙂 Sure but isn't that topic stone dead by now? The OP has taken his ball and gone home and that's the end of that.

I'm sure you understand why. procedure TFooBar.SetValue(const AValue: TFooFoo); begin var Value := AValue.Transform; FValue := Value; end; Did you mean that there are better solutions? Sure there is but I think this is a case of preferring good enough over perfect.

I'll be happy to sell you a copy.

TFDTable should be able to do all this on its own. You don't need a separate memory dataset. See TFDDataSet.Offline

If you're using ProcessWindowMessage as the WndProc you declared with AllocateHwnd then it's no surprise that ProcessWindowMessage are seeing all messages. The message directive is used to build a message dispatch table but that table is only used if the messages are process via the Dispatch method. You could call Dispatch within your WndProc and have the message routed via the dispatch table (to another method) but there's really no reason for that extra indirection in this case. Just filter directly within ProcessWindowMessage.

A wiki wouldn't require a coordinator once it's set up but it would still need somebody to rule in case of conflicts and since people doesn't agree on style (which is why a style guide is needed in the first place) I don't see a happy outcome of that.

Why put a CC BY-SA license on it then? I don't care either way but as far as I can see that troll is out of the box.

I knew it! https://www.imdb.com/video/vi2049426201

That would be a pity. I found it well written with excellent and relevant content. Unfortunately my own experience is that those that need a style guide the most are also those that are the least likely to read something like it. In my current position one of my responsibilities is to be the source code gatekeeper; I review each and every check-in for code style, bad patterns and obvious weaknesses. We need this because many of our developers are fresh out of school and inexperienced or mainly has C# experience. On top of that much of our code were written by amateurs loooong time ago and is simply horrible. On our required reading list is a very thorough style guide which I repeatedly have to refer to when people, including our lead developer, produce code that plainly demonstrates that they haven't read it. Apparently they simply haven't understood the benefits of adherence to a common code style in a large code base.