FredS

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.

OK but.. it reports compatibility which may be important to know.. Of course TOSVersion has always reported the correct version, blatantly ignoring any attempt by M$ to lie 🙂

It may be time to focus on the positive news, three new skins have been released since Rio. Just waiting for all Development Managers to each write a blog about this exciting new feature 🙂

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

Didn't know that, here is a way to do that within GitHub

I was adding something to a tested function and the only way I could justify not retesting all of it is by using 'goto'..

Used my first 'goto' a couple of weeks ago 🙂

Check, so the free tool can downshift to accommodate Delphi 🙂 http://wiki.freepascal.org/Helper_types#record_helper

Stefan's link shows 75 bugs.. then there are those 'secret' internal ones..

Those are two different things, but using your release to beta test your tool set isn't really for everyone..

Good idea but here is what happened: Was unable to generate the Internal Error this morning The Project Group also contains some components so I right clicked and ran 'Install' After that a 'Build' generated the Error Commented out all 'Assert.' After a bit of tweaking all compiled Was not able to reproduce the Error by running 'Install' again Uncommented chunks of 'Assert.' until I could generate the Error 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..

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

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

Been running into: F2084 Internal Error: AV0A33CEAC-R46DC0000-0 myself, so far 90% of the time it works when I recompile, occasionally I need to comment out a line then compile uncomment and compile. Not very helpful but worth trying Resolving Internal Errors.

Yeah, it most likely will go away if you compile with another language as well 🙂

You didn't actually expect that feature to work did you? RSP-17558 but there could be many more reports if anything where ever done about them. Comes down to managing option sets with Notepad else don't be surprised when things go FUBAR.

Well, or we could just continue to use the preceding class name as the indicator... procedure DoStuff; // interface procedure TMyStuff.DoStuff; // implementation

'Entire Scope' as default might be nice too.

That and your Explorer settings, because what you see there depends on finding a matching icon size/color depth. I used to maintain my own res file due to all the issues that brought up but now use Andy's DDevExtensions:

No, I was going to add what you posted to test but since I use MMX I hardly use that Nav Bar. In a large unit it already failed without in-line variables..

You know MMX is free now thanks to Uwe: https://www.mmx-delphi.de/ I was going to see if I could duplicate your issue but the Nav Bar thing won't even show all helpers/classes in my file never mind testing that..

A little early to be sure but it appears to have solved my painting problem: Thanks Emba.. err.. Andy..

By that you mean the same code but it clobbers any previous version and doesn't install correctly? 'Getit' is a form of 'torture', if I could get 'CodeSite' without it I would never run that thing..

Might be easier just to use the one on GitHub it compiles in Rio.

Yes and best readability. That said I've moved all to Attributes now: [EnumNames('TestEnumAttribute', 'Hello, World')] TTestEnumeration = (First, Second); and to retrieve it: Enum<TTestEnumeration>.EnumName('TestEnumAttribute', TTestEnumeration.First) --> 'Hello' Usually I document where I find this stuff but that seems to have gone missing a quick search didn't bring up any of that but this instead: https://gist.github.com/ortuagustin/6342894207caa0f71a5d23475670281d It sure saves writing a matrix for each Enum you need in human readable form.