FredS

Not sure, thought that exists.. However there is no way to deactivate after a crash. Either way, what you owned yesterday is today only a rental.. and at the mercy of a 'rude' renewal department at that..

To me it sounded like 'the litigation department is bored'..

From the GM: New Updates and Changes to the Registration “Bumps” Policy " We updated our processes and now route all issues raised from users who are not on Update Subscription to Sales and Renewals. "

I often wonder how many issues in a mature product are actually the misuse of Version Control..

It appears that feature is no longer implemented..

Tasks can stay idle for something like 5 minutes and then longer in the retired state.

Not an issue, as I said before 99.9% of the time recompiling fixes it. For the remainder, commenting out a line , any line, do a build all then uncommenting the same line will fix it..

Yeah, except yesterday I tried to compile that project via msbuild and it still generated the same error:

RSP-11530 was fixed for Rio, which means it should also show the correct Build.

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.