Anders Melander

Then it's probably a problem with your browser. [Ctrl]+F5 to do a forced reload or use another browser.

You need to have someone compile and run your project with 10.4.2 in order to conclude that. Right now you only know that your exe reproduces the problem and that an exe produced by one other person doesn't.

To be "Musked" I believe it's called

Strange. The URL seems correct so it's probably just a temporary hiccup with the redirection. 2: You translate the application using the component. If you use the component in multiple projects then you will have to do the translation for each project. That's unfortunately just the way Delphi localization is designed. You can save the translations to the Translation Memory and share that between projects, but it's an almost completely manual process. All the translations are contained in the translation project file (the xlat file). A translator will need amTranslationManager.exe and the .xlat file. I would recommend that you also create a portable-mode configuration file so the translator doesn't need to install anything. I think the docs mention that. Once you receive an updated xlat file from the translator you will have to merge that into your local xlat file using some sort of text merge tool. I suggest placing the file under version control and then use that to do the merge. There is no functionality in BTM to merge two translation project files, although that would be a handy feature. It's still there: https://bitbucket.org/anders_melander/better-translation-manager/src/master/#markdown-header-deploying-a-localized-application The hello_world demo contains an example of how to allow the user to choose the language. As far as I remember there are some other methods buried in the announcement thread: If your text is written as a string (or stringlist) property, then it can be translated. Yes. Individual properties on individual components are individually translated. BTM will help you with the translation of identical texts, but it will not do it automatically since that might not be what you want. Often context matters. For example, if you translate "Cancel"->"Fortryd" then it will prompt you to translate all other occurrences of "Cancel" using the same translation. It will even offer to translate texts that "almost" match such as "cancel", "&Cancel", "Cancel!", etc. Use resourcestrings just like you would use a string constant. The only thing to be aware of is that the resourcestring name needs to be unique within the unit. Resourcestrings are a language feature and as such it is processed by the compiler and the linker (with help from the RTL at runtime). FormCreate is a run-time thing so that doesn't matter; Use them where ever you want. Some prefer to keep all resourcestrings in a separate unit, some prefer to have them at the top of the unit and some to have them declared locally where they are used. I usually declare them with the most restrictive scope I can get away with: unit Foo; implementation procedure DoFoo; resourcestring sFooPublic = 'This is a public, global resourcestring'; // Usable by all that use unit Foo interface resourcestring sFooPrivate = 'This is a private, global resourcestring'; // Usable within unit Foo procedure DoFoo; resourcestring sFoo = 'This is a local resourcestring'; // Usable within DoFoo begin ShowMessage(sFoo); end; end. Note though that FreePascal doesn't support local resourcestrings. In FPC they must be declared globally (i.e. outside the methods/functions).

One needs to take into account that we're not dealing with lines but line segments. Lines have infinite length, while line segments have finite length. We don't want to detect a hit beyond the end of the line segment: I think the following one does the trick. I use it in a bitmap editor for scanline conversion of lines (the above image was made with it). (* Distance from point to line segment. Let A=(xa,ya), B=(xb,yb), X=(x,y) Now, the line between A and B is given parametrically by V(k) = (1-k)A + kB = A + k(B - A) and adding the constraint 0 <= k <= 1 makes V(k) the line segment from A to B. Now, the line through X perpendicular to V(k) intersects V(k) when k equals (B - A) . (X - A) k = ------------------- | B - A |^2 So if k <= 0, X is closest to A, if k >= 1, X is closest to B, and if 0 < k < kp, X is closest to V(k). *) function DistanceToLine(X,Y, XA,YA, XB,YB: integer; var RunLength: Single): Single; function VectorLength(X1,Y1, X2,Y2: Single): Single; inline; begin Result := Hypot(X1-X2, Y1-Y2); // = Sqrt(Sqr(X1-X2) + Sqr(Y1-Y2)) end; var k: Single; dx, dy: integer; begin dx := XB-XA; dy := YB-YA; if (dx <> 0) or (dy <> 0) then begin k := (dx*(X-XA) + dy*(Y-YA)) / (Sqr(dx)+Sqr(dy)); if (k <= 0) then // Point before or at start of line segment Result := VectorLength(XA,YA, X,Y) else if (k >= 1) then // Point after or at end of line segment Result := VectorLength(XB,YB, X,Y) else // Point within line segment Result := VectorLength(X,Y, XA+k*dx, YA+k*dy); // = VectorLength(X,Y, (1-kp)*XA+kp*XB, (1-kp)*YA+kp*YB); RunLength := k; end else // Degenerate line begin RunLength := 0; Result := VectorLength(XA,YA,X,Y); end; end; The result is the distance, the RunLength parameter can be used to determine where the projection of the point onto the line lies: before, on, or after the line segment. A small optimization can be done since we're doing hit-testing and don't really need the actual, precise distance value. The VectorLength function uses Hypot (i.e. Pythagoras) to calculate the distance. Hypot internally does a Sqrt, which is an expensive operation. The Sqrt can be eliminated so we return the squared distance instead and then we just need to compare that value against the squared hit limit instead. I.e. if your hit limit was 4 then compare the squared distance against 4*4 = 16 instead.

I have attached an extraction of the BTM documentation I have. As I said it was written for use with a specific project (called FooBar in this version) and as such contains references to the setup of that project (folders, config files, etc.) and it assumed that the initial translation project file and update have already been done. The source document, as mentioned, comes from Confluence so the formatting of the exported document is a bit wacky, but I think it should be readable. Using_Better_Translation_Manager_-_Anders.Melander_-_Confluence_(2023-08-16_22_10_10).html

I have no idea what you are referring to.

Ah, that... Um... Eh... I don't really have anything besides what's on the Bitbucket page. Well, actually, now that I think of it I think I have something in a corporate Confluence page somewhere, but I will have to revise it for public consumption and it's probably targeted for use with a specific commercial project. I'll look into it later tonight.

Done. The new version is 2.0.8628.33873

What help is that? Yes, I see it. Apparently, the feature branch wasn't merged correctly. I'll get that fixed.

Convert the bezier to a polyline with a fixed limited number of points (whatever drawing routine you end up using already does this internally, you just need a lot fewer points for hit testing than for drawing a smooth line). Iterate the segments of the polyline and find the minimum distance from your point to the segments. Even with thousands of beziers, you should be able to do this in no time at all (I'm guessing low milliseconds).

Fixed. The purge was rejected unless the project contained obsolete items with translations. Get the new release (2.0.8628.30767) here: https://bitbucket.org/anders_melander/better-translation-manager/downloads/ Changes since the last release (2.0.8370.39904): Fix for unable to purge project unless it contains Unused translations. #43: Specify external PE resource module stub via command line #41: DeepL Integration Added Save As... action. Previously the Save action always prompted for filename.

Reproduced. I'll investigate now.

No, you're right; They cannot. Assuming this means that you cannot purge them, can you zip the translation project (just the xlat file) and post it as a DM to me.

That's "obsolete" items. Items that existed in a prior version of your application but which have been deleted since they were first imported. That usually happens when you delete components or units. You can't really hide them (that's a missing feature) but you can delete them: Or you can just mark them "Don't translate" and hide them that way. The reason they aren't just deleted automatically is that their translations (if they have any) can be reused by other items. For example, if you rename a component, then the translation-to-component link is broken but by comparing the source texts, BTM can move the link to the new component so the translation isn't lost. The Recover action does this. The translations of obsolete items are also still used as translation suggestions.

If you are not actually using that string anywhere then it's probably being eliminated by the linker. Resourcestrings are only ever loaded from STRINGTABLE resources and the STRINGTABLE resources (and the .drc file) are produced by the linker based on the units linked into the application. If you add a ShowMessage(aa) to the above example then I bet the resourcestring will appear. Regardless, I think we can conclude that this isn't a BTM problem.

Can you see the resourcestring in the .drc file? [edit] Btw, have you remembered to update the translation project after these changes? If you don't update the translation project it will only contain the strings that were in your project when you created the translation project.

That's the newest release; It's from December 2022. I don't know where you you got the year 2019 from. Nothing special needs to be done. If the resourcestring is implemented in unit XXX and you drop a component from XXX onto a form in unit YYY of project ZZZ, then the IDE will include unit XXX in unit YYY's uses clause and when you compile ZZZ, the resourcestring will appear in the ZZZ.drc file (it's a text file) located the sample place as ZZZ.exe. If you don't have ZZZ.drc then you need to configure your project to produce that file (see the project linker options) - but BTM should complain if it can't find the file.

All resourcestrings, regardless of the unit they come from, are listed under the Resourcestrings module node.

I'm still not sure what you're saying - or asking. You hide rows by filtering them out: Hover over the Status column header, click the button that appears in the header. Select the statuses that should be visible. Like in my screenshots. That's not really a question, but anyway: If your component strings appear in the string grid, then they can be translated; All resourcestrings and published component string (and string list) properties can be translated.

I'm not really sure if this is what you're asking for but you can indicate which modules to translate and which to ignore by right-clicking and changing their status: and then you can filter on the status: You can do the exact same in the string grid:

I doubt that it's DevExpress that's slowing your project load down. I always have it installed and do not have any problems with it. It's more likely the livebindings design-time support that's the culprit (at least it used to be a common cause of slow downs). Try disabling the livebindings design time packages and see if that helps. The attached .reg file does that for Delphi 10.3, 10.4, and 11.x You may need to reinstall DevExpress afterward as I believe some of their packages have dependencies on the livebindings packages. disable delphi livebindings.reg

Why would that make a difference? The whole directory/tree would need to be scanned anyway, even if he's only interested in the image files. [edit] Oh, I guess you mean select files based on the filename as opposed to the file content. I would probably go for an in-memory database (e.g. SQLite or even just a TFDMemTable) for the index but store the files on disk (but don't put all files in a single folder - that will suck). That said, if you have 50K files averaging 30Kb each, that's only 1,5 Gb total (+ overhead) so you could actually fit the whole thing in memory.

Ray Lischner. He wrote 3 Delphi books, AFAIR, none of them about component design. I've got "Delphi in a Nutshell" (basically just a reference book) and "Hidden Paths of Delphi 3" (about the old open tools API). Both had horrible binding and fell apart right away.

It was aimed at SQLite but it was not meant as a dis. As long as the limitations and risks are taken into account it's a fine embedded database engine. I haven't used it in a while but I have just read through the technical documentation and I can see that a lot has been done with regard to reliability since then. Still, after having read the docs I couldn't help but feel that there were problem areas that were brushed over or simply left out.