dummzeuch

Hm, good point, I'll have to check that too. Edit: No, doesn't happen.

Yes @Anders Melander, you are right in all points. Unfortunately none of the options you mention was possible in this case (Delphi 6 -> no Generics, Objects already used). I could also have used TStringList.Objects to store the old index and use Sort, just as you describe for TList<integer>, but that wouldn't have helped much in this particular case. The point of this post was that everything else is better than directly using the Items property and that it is not obvious why. A virtual CheckListBox would have been even better, but that code is broken since like forever.

I think you meant "worse" here.

This should do the trick: function GetSetCardinality(const aSet; aLen: Word): Word; var B, i: Integer; abyte: PByte; begin Result := 0; abyte := @aSet; for B := 0 to aLen - 1 do begin for i := 0 to 7 do if (abyte^ and (1 shl i)) <> 0 then Inc(Result); Inc(abyte); end; end; test code: var SomeSet: set of 0..255; Count: Word; begin SomeSet := [1, 5, 6, 100, 200]; Count := GetSetCardinality(SomeSet, SizeOf(SomeSet)); Count should be set to 5, the number if elements in the set. ALen should be 32. var SomeSet: set of 0..10; Count: Word; begin SomeSet := [1, 5, 6]; Count := GetSetCardinality(SomeSet, SizeOf(SomeSet)); Count should be set to 3, ALen should be 2 (one byte has 8 bits, the set can have 11 elements (0..11) which is > 8 and <= 16 -> 2 bytes.

Even worse: It provides a false sense of security and on top of that results in a runtime error that isn't really an error in this case. On the other hand, there is the aLength parameter which supposedly contains the length of the aSet parameter in bytes and there is nothing to prevent it from being larger than Length(bytes) (Assuming that aSet is a set as the name implies it has a maximum size of 32 bytes = 256 elements, each represented by one bit). Using a PByte would probably be better here and some comment would also be in order.

Why are these dates stored as strings in the first place? If they are in a database they should be in a date field. If they were entered with a date picker, they should be TDate or TDateTime variables. If you want to store them as strings in a database for whatever reason, store them in a standard format: ISO 8601, and document that format. Don't rely on your users having Windows configured for any particular date format, you will find somebody who didn't, especially if your program is used in more than one country. And keep in mind, that date formats can be ambiguous: 01/12/15 can be 12 January 1915 or 12 January 2015 (American format), 1 December 2015 (British format), 15 December 2001 (some MSSQL format that looks like they got ISO 8601 wing). The only one I haven't seen so far is using the middle term for the year, but I'm sure some idiot will come up with that too. TryStringToDate by default uses the Windows settings, so that's out in this case. I wrote my own conversion and checking code for ISO 8601. It's in my dzlib if you are interested.

Just remembered capecod gunny (Michael Riley) who wrote some financial software in Delphi. Not sure whether it can apply here because it seem very specific to - in my view - typical American problems. https://www.zilchworks.com/zilch-standard.asp

Excel is a nice tool for simple everyday tasks. It becomes a support nightmare once it somehow gets involved in the business procedures, because of course everybody thinks he is an expert in Excel and knows exactly how to use it and how to change stuff. Sooner or later you will end up with a monster spreadsheet that nobody can understand. As to the topic: Either people know how to use spreadsheets, then they will probably already use it for that task, or they don't, in which case they most likely will be overwhelmed when you give them anything more than a table with a few sums. Will they pay you for support? By the hour? If not, don't use Excel. You will end up either spending a lot of unpaid time for support or they will hate you, because you don't.

The current version doesn't work with Delphi (as reported in that project and in the SemanticMerge forums). I fixed that issue a while ago, but by now even that fix might no longer work: https://github.com/dummzeuch/pas2yaml But I don't use it (I only tried it for a while), so I don't really care.

I think you are, because a different monitor resolution won't change anything for the position or size of a control. Only different pixel densities will, but these properties won't help there either. But whatever the reason for these properties, they are an annoyance and not useful for most people.

That would only make a difference if I received more than one patch per month. Currently I'm not even getting that "many". I doubt that switching to Github would result in more. It didn't work for other Delphi related projects, as far as I can see.

Yes, that was in other projects. For graphics32 there was only the one you saw. But I could probably also submit packages for other Delphi versions that currently don't exist. Yeah, that has happened / is happening with many Delphi libraries. I was shocked to find that Indy has only one developer left. dxgettext is mostly dead too, I get the odd bug report or sometimes bug fix which I try to apply, but I'm not the project lead, I only happen to still have write access to the repository, and Lars seems to be no longer much interested.

Try the attached project files. They go into a subdirectory Xx10.0 under source\packages. They compile for me, haven't tried to install them though. Graphics32_Delphi10.0.7z Yeah, great. I just submitted a pull request for theses files and got an email from Github that they will be disabling login with passwords by August 2021. They give several hints on what to do, but don't mention the svn bridge. I guess that's it then: No pull requests from me on Github any more. They got ignored most of the time anyway...

The JVCL also comes with some graphics manipulation functions. They look very similar to those in Graphics32 to me, so they might come from the same origin.

I just converted your code into an expert in revision #3418

What is GExperts? GExperts is a plugin for the Delphi IDE that adds many enhancements and also fixes some bugs. Which Delphi versions are supported? By the time of this writing GExperts supports Delphi 6 to 10.4 (with the exception of Delphi 8). GExperts releases always support/require the latest update for each Delphi version available at the time of the release. Where can download it? There is a link to downloads for the current and older releases on https://gexperts.dummzeuch.de I found a bug, what do I do? Please file a bug report. If you happen to have already fixed this bug, please also attach a patch or an archive with the changed source files. I have a brilliant idea for an improvement. What do I do? Please file a feature request. I have added some improvement to GExperts. Where can I submit it? Please also file a feature request and attach a patch or an archive with changed source files. Why shouldn't I report bugs an request features through this forum? I prefer to work on the actual program rather than being my own secretary. Taking posts from the forum and create the bug reports / feature requests is boring and time consuming work. I don’t want to do that work. Where is the source code? See compiling your own DLL. Why is GExperts still on SourceForge rather than on Github like all the other important projects? I happen to like SubVersion better than Git. Github does not support SubVersion (apart from a bridge with limited features). What if I have a question not covered in this list? There is a more comprehensive list of frequently asked questions on my homepage Additional questions can of course be asked in the forum.

I second that, but as always I would prefer text + screen shots over a video because it's searchable and I can easily jump between the parts that are currently important for me.

https://gexperts.dummzeuch.de has a menu "GExperts" which looks like this ... ... and links to pages that in turn have links to: https://sourceforge.net/p/gexperts/bugs/ and https://sourceforge.net/p/gexperts/feature-requests respectively. The bug report / feature request dialog in GExperts also links there. Regarding pull requests: Since this is not github, there is no such thing. If you want to contribute, post a feature request or bug report and attach a patch or, if you prefer that, an archive with the the changed sources. If you plan to contribute regularly, you can get write access to the svn reqository. @Daniel Would it be possible to make a sticky post in this forum with this information?

Now that you mentioned it, I remember that I always wanted to try that tool as soon as I move to a more recent Delphi version...

As I wrote: This works find for libraries. Components are a problem, because they are installed globally. There are various solutions for that too, e.g. custom registry branches, but they are a pain in the lower back anyway.

Another option is to use relative paths and have all libraries as a subdirectory of the project. As they belong into source control anyway, we are using svn:external for that. Works fine for libraries and less well for components since the IDE does not support it really and most component installers insist on using a global directory.

I just found this code in vcl.forms in Delphi 10.2.3: function ShouldScale(const self: TCustomForm): Boolean; // this is just to make code more readable begin Result := self.FScaled and not (csDesigning in self.ComponentState) and ((self.Owner = nil) or not (LowerCase(self.Owner.ClassName) = 'teditwindow')) // we are not in an edit window and ((self.Parent = nil) or not (csDesigning in self.Parent.ComponentState) or not (csFreeNotification in self.Parent.ComponentState)); end; What is this comparison with 'teditwindow' about? Looks as if somebody had to add this to make the IDE behave. What if somebody's program uses a form called TEditWindow?

The best way to get this implement is a feature request on SourceForge. And don't assume that everybody knows how TMS Web Core works (I don't). You must be specific on how the expert is supposed to determine which files to back up. An example project with that description would also help. And if it is really important for you, you could implement it yourself and contribute that code. That's the fastest way to get it into GExperts.

Even later, there were the Turbo Explorer Editions (Delphi 2006) which were also free.

Wow, after the first sentence I thought you were talking about Delphi 2007 or even older. We recently started to move to 10.2 after never finishing the move to XE2. And no, in this case it wasn't management who delayed this, it was me. It took a long time to get to a state where I am confident that the current code base can be moved to Unicode without breaking it all over the place. On the other hand I am currently working with Delphi 2007 again on one of the older tools where I'm again not confident enough that it won't break moving it up to 10.2. Maybe that's a mistake, I should probably just work with 10.2 and only go back to 2007 if there are any problems. Given the impression of 10.3 and 10.4 stability I got from working on GExperts, I'm not even considering going to anything more recent. Theming seems to have broken so much of the IDE, it's not funny. Back to the topic of CE: I seriously doubt that we will see a 10.4 CE before 10.5 (or wherever it will be called) becomes available. And I will be surprised if that happens even then. (Just in case anybody is wondering: No, I have no inside information from Embarcadero, I'm not even an MVP or in the beta test. All this is simply my opinion and observation.)