dummzeuch

I just downloaded the 30868_bde_installer_for_rad_studio_delphi_c_builder_10.3_rio.ZIP from Embarcadero and tried to install the BDE on a computer that I want to run some programs that still depend on the BDE. And I got the following error: --------------------------- No Rad Studio 10.3 found --------------------------- BDE install can not continue because Rad Studio 10.3 could not be found on the system. Please install Rad Studio 10.3 and try this install again. --------------------------- OK --------------------------- WTF? Does anybody know how I can install the BDE on a computer that does not have (and will never have) Rad Studio installed? Is there a separate installer for that? (And please refrain from telling me that we should get rid of the BDE already. We're getting there but we're not there yet.) twm

If you only ever handle files created with Windows programs, that's probably fine. Unfortunately I also get files from other systems, where the BOM might be useful.

The parser still has bugs. It could be as simple as that. If you can produce a small excerpt of the unit that produces this behavior I will have a look.

IT'S A PROBLEM IN THE BUILD PROCESS THAT ONLY AFFECTS THOSE WHO USE IT. I DON'T CARE IF YOU CALL IT A BUG, FOR ME IT'S AN ANNOYANCE AND THERE IS A SIMPLE WORKAROUND THAT TAKES ALL OF 30 SECONDS TO APPLY. FIXING THIS SO CALLED BUG WOULD TAKE ME AT LEAST HALF AN HOUR. AND THAT'S MY TIME, NOT YOURS. (OK, I will stop using caps now.) I won't take the time to fix this, it doesn't affect me. If you want it fixed, fix it yourself.

No, I won't. It's just an annoyance and can be worked around easily. But if you think it is worth your time: Go ahead.

I was just about to say that Alt+I is already taken by some other function, because I distinctly remember not setting it for some reason, but apparently it isn't and my memory is wrong. So: Done in revision #3063

OK, I know what the problem is: The GExperts build scripts do not support paths that include a space character. (Which is actually documented.) Rename your "GExperts Sourcecode" directory so it does not contain a space character and it should work.

I just tried to reproduce this problem: * Deleted all files in the Projects\DelphiXx103 that are not under source control (including the GExpertsRS103_Version.RES file you mention * Deleted all files in the dcu subdirectory * run the _Build_Project.cmd file I got no error messages.

There was once: Look up STColl (part of TurboPower's tpsystools): - STCOLL theoretically allows up to 2 billion elements. The collection is "sparse" in the sense that most of the memory is allocated only when a value is assigned to an element in the collection. - STCOLL is implemented as a linked list of pointers to pages. Each page can hold a fixed number of collection elements, the size being specified when the TStCollection is created. Only when an element with a given index is written to is a page descriptor and a page allocated for it. However, the first page is allocated when the collection is created. Unfortunately TurboPower went out of business back in - hm, the article on slashdot says 08/01/03, so was it 2008 or was it 2003? Damn stupid American date format - I think it was 2003. Their libraries were open sourced though.

There are other structures that don't actually need contiguous areas of memory, e.g. linked lists or some tree structures. But of course these have other weaknesses.

Hm, looks like somewhere a relative path is resolved wrongly. GExpertsRS103.res is not the same file as GExpertsRS103_version.res. The former is automatically created by the IDE and should not be referenced in the project. The latter is supposed to be generated by the pre-build script, which reads the version number from the GExperts_version.ini file, creates an .rc file from it and then compiles it to the .res file. Apparently that process is broken.

And also: Responding to any questions that may follow. (Unfortunately I am guilty of not answering questions to some of my QC(?) reports: When I'm on holiday I simply can't. Guess what? They closed the report.)

Was there ever a Delphi version which wrote a project version of 17.3 into the .dproj files? <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <PropertyGroup> [...] <ProjectVersion>17.3</ProjectVersion> </PropertyGroup> As far as I know there was no such version. 17.2 was Delphi XE8 and 18 was Delphi 10.0 Seattle. Apparently Project JEDI generates .dproj files with project version 17.3 for all Delphi versions >XE8,

AppMethod ? Possible, according to Jeroen's list it existed until Delphi 10, so it might have used ProjectVersion 17.3. But I found that JEDI uses that version in the packages for all Delphi versions >XE8, so even if I assume AppMethod, it would still be wrong. (Background: See my blog post on dzBdsLauncher)

So, we conclude: They limit the number of testers => Don't want them to find bugs? On the other hand: Many bug reports are that bad that they are not worth the time you spend reading them. (But in my experience the majority of bug reports are good.)

The latest version of dzBdsLauncher can now also handle some .dproj files with invalid ProjectVersion entries (e.g. those generated by project JEDI which apparently uses ProjectVersion 17.3 for all Delphi versions >XE8). It does this by evaluating the DllSuffix entry, if one exists. This can also help solving conflicts if the ProjectVersion is not unique. In addition the tool can now also open .grouproj files. read on in the blog post.

Today I released version 1.0.2 of dzPackageInst. Its a command line tool that allows installing and uninstalling design time packages into the Delphi 6 to 1.3 IDEs. read more in the blog post

Actually it's much easier to get money from management for an update whenever it is being released than skipping a few versions and then argue that a particular release is so important that you must buy it. It's even easier with a subscription because then you don't have to argue at all, once you got the subscription. This gets worse with company size. Of course that particular reason might not be valid for you or your company.

Which version of GExperts and which version of Delphi are we talking about? (Did you create a bug report?)

I agree, mostly, at least when it comes to upgrading from 10.2 to 10.3. The disadvantages of the unstable IDE offset the advantages of new language and IDE features by far. But I would have upgraded from 2007 to any XE version (up to 10.2) if it weren't for the subtle bugs the Unicode transition is likely to bring to code that isn't prepared for it (we still have code that uses strings as buffers for binary data, even though I have cleaned it up a lot). There are of course no unit tests for this legacy code, and on top of that they are difficult to write, because they usually rely on some hardware to communicate with. And just to add more fun, this code must run on Windows XP, which is no longer officially supported by the RTL and even less by the IDE (did anybody try to install recent Delphi versions on XP? I would be interested in your findings). That is a major stumbling block(?) right now.

It's a hack (there is no OTA access to the debugger in Delphi 2005 to 2007): The plugin reads the output memo from the dialog and then tries to convert it. It then directly writes the result to the memo. That has some drawbacks of course: long text is truncated so the conversion won't be complete. Float strings do not have the full precision, so converting them to TDateTime is also restricted in the precision, mostly on the time part. Yes, I decided that apparently nobody is interested, so I simply kept it to myself. If anybody wants it, I'll make the source code available (if I can still find it).

Just in case somebody needs TStringList and TDateTime visualizers for Delphi 2005, 2006 or 2007: here you go

Actually when I did some performance comparisons between Delphi 2007 and 10.2 with the same code and the same compiler settings, I got some noticeable improvements (yes I did timings). That's one particular program though and it is doing heavy graphics manipulation with mostly integer arithmetics, but still, it's evidence that the compiler was indeed improved since 2007. I can't say anything about improvements over the last few releases though. And the IDE is definitely eating more CPU in every new release.

Good point, I added the manual test later to make THashedStringList work with the same code as a sorted TStringList. It shouldn't hurt performance though since the expensive search code is executed anyway to find the place for inserting the new string. btw: I appreciate your feedback on the testing code, even if it might not have sounded like I did.

Obviously, as you pointed out yourself, I am adding duplicates, which the string list should ignore. (That actually is based on my "real world" usage of the list which I want to replace.) I know of no way to achieve that otherwise, or is there one that I don't know about?