Anders Melander

I dnt knw bout u, bt I gt $ 4 the Q of my cde. Not for the amount of keystrokes I can save.

You mean to say that you've memorized all the 16 hex digits? Wow

I'm still hoping that with will be completely eliminated from the language. Here's a few lines from the code I'm currently working on: begin ...3-400 lines of code... with vPlan.DataController, dbSlaktePlan, BLPlan, Grupper ,Data[Id] do begin ...a few hundre lines more... with vPlan, BLPlan.SiteSum, Plans[Id] do begin ...and it goes on...

It seems to me that what you're describing is beyond the scope of localization and therefore BTM. BTM is a localization manager/editor. It provides translations to the standard localization mechanism built into the Delphi RTL. If you're not using that, and it doesn't sound like it, then I can't see how BTM can meet your needs. That said, the translated resource modules generated by BTM are just DLLs containing the translated resources (i.e. resourcestrings and DFMs). This means that you can use regular Windows APIs to load and extract the resources from these resource modules. It's also possible to hook into the resource loading mechanism and redirect the loading of selected forms to other resource modules. This could provide the multi-language capability. You could also just read the translation project file (it's XML) and extract the translations from there. But, to be honest, none of the above sounds like a good path to go down.

Yes but that was not what you wrote.

*cough* WideString *cough* Available since D4 or thereabouts...

Yet again the duck proves that it's invaluable.

ArduPilot and QGroundControl not working for you?

Yes. Without that I wouldn't use them.

Fair enough. I've come to use them a lot. Often I have to remind myself to use a new feature after it's introduced but this one feels so natural that I'm not thinking about it all. If anything I have to remind myself not to use it too much. The ternary operator. Didn't like it when my main language was C++ and I still don't like it. For me it somehow breaks the flow when I'm reading code.

Why so sad? Because of the leak?

I would examine the call to Save in the CPU view in the debugger to determine when, and if, the passed variant is cleared. I remember there was some leakage issues surrounding variants passed as value parameters to dispatch interfaces but I can't remember the details anymore. Not related to your leak but: Instead of String(AInputVariant) you could do: VarToStr(AInputVariant) Instead of copying the TStringStream to a TMemoryStream, why don't you just operate directly on the TStringStream? lStringStream.Position := 0; lOutputStream.CopyFrom(lStringStream, lStringStream.Size); is the same as lOutputStream.CopyFrom(lStringStream, 0);

If you could define what "some json issue" is then we (and you) would have a chance of actually solving this problem. Right now we're all just guessing.

Yeah, there's that. My point was more that the Delphi does much more. Not that it wouldn't be nice if they made it more or better "pluggable".

So, you do a lot of GUI design, debugging and building in VSCode?

Remember that we're talking about UCS4StringToWideString and not WideStringToUCS4String but I'll try again: Yes, it's a given that the resulting string, which is a 2 byte widestring, will be zero terminated as all Delphi long strings are. If the input was a PUCS4Char (a pointer to a zero terminated 4 byte string) then the input would have to be zero terminated. But it isn't. The input is an array in which the length is implicit. This means that the zero termination requirement is superfluous. The function could be implemented so that it handled both arrays with and arrays without a zero in the final entry. You know; Defensive coding. Just in case someone mistakenly passed an array that wasn't zero terminated because the documentation didn't state that you had to...

Okay. Yes, I can see that there's a git merge --squash command. So I guess SourceTree squashes commits by default because when I merge and push I only get one new commit in the history of the target. The only reference to "squash" that I've come across in SourceTree is in the Interactive Rebase dialog (which I don't understand enough to dare use).

I meant the function doesn't need it to be zero terminated (it has the length already).

So how do you deal with mapped drives, mounted volumes, symbolic links, junctions and hard links?

Squash? But that's a rebase thing, right? So how can you squash without rebase? Anyway. Let's say I have my 'master' commit history: 1. Initial commit 2. Made some changes 3. Fixed some changes At commit #2 I branch 'master' into 'FooBar' and make "a few" commits to that branch: 1. Experimental stuff 2. Enhancements ... 999. Refactorings 1000. Updated easter egg Now I merge my 1000 commit branch into master (resolve conflicts etc): 4. Merge branch 'FooBar' into 'master' And push. So the now 'master' commit history will read: 1. Initial commit 2. Made some changes 3. Fixed some changes 4. Merge branch 'FooBar' into 'master' Are you saying that you'd want the whole 1000 'FooBar' commits to appear in the 'master' commit history? I can see that if you don't have 'FooBar' pushed to the remote then the history will be lost, in which case it makes sense, but if you have pushed it, then there's no need to duplicate that history in 'master'.

You didn't answer any of the questions.

I'm not sure I agree with it. As I read it, and I may well be misunderstanding it, it assumes that when I merge my 1000 commit feature branch into master that I want all 1000 commits to appear in the master commit history. Well I definitely don't. The 1000 commits are the sausages being made and I only want the finished sausage in the master commit history. There's also this: What it should have said is: never rebase a public branch. It's perfectly safe and normal to rebase a private branch on a public branch. Assuming on=onto. Maybe that's what he meant.

Well I meant without opening the file. Of course Windows itself is able to determine if two local files are the same. If opening the file is OK then, yes GetFileInformationByHandle will get the job done. There are also other API functions that can be used if opening the file is okay. For example the undocumented NtQueryObject API can be used to get the logical filename of just about anything (e.g. C:\Windows -> \Device\HarddiskVolume1\Windows). The PIDL solution definitely won't work. PIDLs live in the shell namespace and you need to go much lower than that to determine identity.

There's no need to state the obvious. While the function may behave as designed, it's at the very least poorly documented. I looked at both the documentation and the implementation before I came to the conclusion that there was a bug. I'm fine with the implementation staying the way it is (to avoid breaking existing code) but it should be documented that the array is assumed to be zero terminated. Actually since the array doesn't need to be zero terminated (we know the length of the "string" already from the array) I can't see why the zero termination couldn't be made optional. Either way: fix the documentation.

Ah. I didn't check the source. I just assumed the documentation was correct. Silly me