Jump to content

FredS

Members
 View Profile  See their activity

  • Content Count

    430

  • Joined

  • Last visited

  • Days Won

    4

Posts posted by FredS

  11. Posted

    8 hours ago, dummzeuch said:

    Are you sure about that?

    Yes, one of the first things I did back in XE7.

     

    However 

    Writeln(TOSVersion.ToString);

    returns: Windows 10 (Version 10.0, Build 0, 64-bit Edition)

     

    Because in in TOSVersion.Create: 

        if not GetNetWkstaMajorMinor(MajorNum, MinorNum) then
      GetProductVersion(kernelbase, MajorNum, MinorNum, BuildNum);

    The call to GetNetWkstaMajorMinor doesn't return a Build, if it failed GetProductVersion would have returned the correct Build.

     

  14. Posted

    36 minutes ago, dummzeuch said:

    It's really annoying that it is that complicated

     

    There is a benefit in maintaining your own fork, wish it was simpler to find the most up to date fork though and fork that 🙂

     

    Also generating a branch before a making a pull request isn't a big deal as long as one knows about that..

     

  21. Posted

    1 hour ago, Stefan Glienke said:

    then look for Assert.something calls

    Good idea but here is what happened:

    1. Was unable to generate the Internal Error this morning
    2. The Project Group also contains some components so I right clicked and ran 'Install'
    3. After that a 'Build' generated the Error
    4. Commented out all 'Assert.'
    5. After a bit of tweaking all compiled
    6. Was not able to reproduce the Error by running 'Install' again
    7. Uncommented chunks of 'Assert.' until I could generate the Error
    8. But commenting those back in still generated the Error after running 'Install'

    As I have postulated for years, the compiler appears to get confused about which directory its in or something else internally goes haywire.
    The degree of which appears to get better or worse with each release..

     

    Just to be clear; 'Install' is executed via the context menu so the active project does NOT change in the Project Group. Certainly rhymes with the 'I did a few things and it broke' we see a lot..

     

  22. Posted · Edited by FredS

    1 hour ago, Rudy Velthuis said:

    Look for code that does this

     

    Right, its 163k lines of code that compile fine unless I switch to the DUnitX Build Configuration which is full of generics and anonymous methods and my implementation uses a ton of directives..

     

    There is no logic, you can't comment out some fixtures and get it to work consistently but you can simply comment out any random line and compile twice to bypass it. Compiling in Rio seems to work, of course that has other issues..

     

  23. Posted

    1 hour ago, dummzeuch said:

    I am apparently too stupid to work with git

    "GIT - the stupid content tracker"

     

    In GitHub click 'Fork' on the jvcl repo, use that repo for your local feed.
    Push your changes to that repo, then use GitHub 'Pull Request'.

     

    In the end it works out to be a better system, you have a copy of the code you are using in GitHub, regardless of jvcl integrating it or not.
    When jvcl is updated you can use GitHub to see any changes before deciding to update your Fork.

     

    One of the recent 'TortoiseGit' versions has a create Pull Request URL now, but I haven't used it.

     

×