Jump to content

Anders Melander

Members
 View Profile  See their activity

  • Content Count

    2854

  • Joined

  • Last visited

  • Days Won

    156

Posts posted by Anders Melander

  2. Posted

    6 minutes ago, dummzeuch said:

    Don't expect this to keep working in future Delphi versions.

    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...

     

    • Like 1
    • Sad 1

  3. Posted

    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.

  9. Posted

    45 minutes ago, aehimself said:

    I just personally dislike inline variable declarations.

    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.

     

    47 minutes ago, aehimself said:

    the "?" operator

    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.

    • Like 1

  11. Posted

    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:

    1. Instead of 
      String(AInputVariant)
      you could do: 
      VarToStr(AInputVariant)

       

    2. Instead of copying the TStringStream to a TMemoryStream, why don't you just operate directly on the TStringStream? 

    3. lStringStream.Position := 0;
lOutputStream.CopyFrom(lStringStream, lStringStream.Size);

      is the same as 

      lOutputStream.CopyFrom(lStringStream, 0);

       

  13. Posted

    13 minutes ago, Lars Fosdal said:

    the ease of upgrade of the IDE and it's plug-ins

    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".

  14. Posted

    25 minutes ago, Lars Fosdal said:

    Whenever I am in VSCode, I am looking at the Delphi IDE and sighing.

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

  15. Posted

    10 minutes ago, pyscripter said:

    Why should any Delphi program use UCS4?  The main use case is for inter-operability.   You would need to pass the result to some external function.   Having to manually add the null-terminator, would be inconvenient.

    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...

  16. Posted

    45 minutes ago, Fr0sT.Brutal said:

    squash is just join all commits into one

    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).

  18. Posted

    37 minutes ago, Remy Lebeau said:

    Get the IShellFolder interface for the root Desktop namespace, pass both filesystem paths to its ParseDispayName() method (short paths, long paths, it doesn't matter), and it will ask the filesystem to parse them and provide absolute PIDLs, which will compare equal if they refer to the same file.  Trust me, it works, I use it.

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

  19. Posted

    24 minutes ago, Dalija Prasnikar said:

    But when you are merging without rebasing, you also get the whole sausage, unless you squash.

    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'.

  21. Posted

    6 hours ago, Dalija Prasnikar said:

    I found this answer on Stack Overflow about merging branch to master. Maybe it will help. https://stackoverflow.com/a/29048781/4267244

    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:

    Quote

    The only thing you need to avoid is: never use rebase on public branch, like master branch

    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.

  22. Posted

    3 hours ago, Remy Lebeau said:

    Yes, it is.  In fact, there are several way to do exactly that.  For example, parse the 2 paths into absolute PIDLs, and then see if they compare equal.  Or, open the files, retrieve their volume serial numbers and file identifiers with GetFileInformationByHandle/Ex(), and see if they compare equal.

    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.

  23. Posted

    2 hours ago, Remy Lebeau said:

    UCS4String is not a native RTL string type, like (Ansi|Unicode|UTF8|Wide)String are.  It is just a plain ordinary dynamic array of UCS4Char

    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.

    • Like 1

  25. Posted

    10 minutes ago, A.M. Hoornweg said:

    The prefix "\\?\" is a well-known method to tell Windows that a program is able to parse file names longer than MAX_PATH. It seems that the prefix \\?\UNC\  extends this ability to network paths. Otherwise I wouldn't bother with them.

    \\?\UNC\ isn't an extension of \\?\

    https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file#win32-file-namespaces

     

    Quote

    For file I/O, the "\\?\" prefix to a path string tells the Windows APIs to disable all string parsing and to send the string that follows it straight to the file system.

    [...]

    Because it turns off automatic expansion of the path string, the "\\?\" prefix also allows the use of ".." and "." in the path names, which can be useful if you are attempting to perform operations on a file with these otherwise reserved relative path specifiers as part of the fully qualified path.

    Many but not all file I/O APIs support "\\?\"; you should look at the reference topic for each API to be sure.

    This means that if the path starts with \\?\ then what ever follows is beyond what ExtractFileDrive was meant to handle. It could attempt to just strip the \\?\ part and retry but it I think it would be reasonable to give up and just return an empty string.

     

    19 minutes ago, A.M. Hoornweg said:

    I needed to test if two paths referred to the same volume

    Good luck with that. It isn't even possible to determine if two fully qualified paths refer to the same file.

×