PiedSoftware

Thanks, emailx45. I have posted an archive as an attachment to the opening post. It is the pas, dfm and dpr / drpoj files. It should be self explanatory. Of course it may be a bug that is fixed in later versions of Delphi and/or JVCL. Update: I have just added a pair of screenshots to show the correct look of the menu from the sample code and the incorrect look from my code.

Hi Does anyone have any working example code for implementing a spell checker? I tried this https://www.thoughtco.com/spell-checking-from-delphi-code-1058149 but it doesn't compile, giving lots of Undeclared identifier errors.

Are you using the OnUpdate events of the individual actions? If so, IIRC, that only gets called if there is a control attached to the action and that control is visible.

Hi, I was surprised when a simple bit of code did not compile for me. I am using Delphi 10.1, and TEditCharCase is defined in System.UITypes thus: TEditCharCase = (ecNormal, ecUpperCase, ecLowerCase); I have a property of that type in a class TMapItem declared thus: property CharCase: TEditCharCase read fCharCase write fCharCase; Control clicking on TEditCharCase takes me straight to that line in UITypes. But when I wrote this innocent looking code: case mapItem.CharCase of ecNormal: expr := value; ecUpperCase: expr := value.ToUpper; ecLowerCase: expr := value.ToLower; end; it refused to compile, saying "E2003 Undeclared identifier: 'ecLowerCase'", etc for the 3 enumerated constants. But I got it to compile by prefixing the constants with the type name, thus: case mapItem.CharCase of TEditCharCase.ecNormal: expr := value; TEditCharCase.ecUpperCase: expr := value.ToUpper; TEditCharCase.ecLowerCase: expr := value.ToLower; end; This is strange. There are lots of places of enumerated types that don't need to have the type prefixed. Can anyone explain this? TIA Mark Patterson

I noticed in the library source code that some of the uses of TEditCharChase constants were not prefixed with the type. For example, in DbCtrls there is this: case CharCase of ecUpperCase: S := AnsiUpperCase(S); ecLowerCase: S := AnsiLowerCase(S); end; When you ctrl-click the constants there you are sent to a line in StdCtrls that is part of this sequence of declarations: const { Editors common support } ecNormal = System.UITypes.TEditCharCase.ecNormal; ecUpperCase = System.UITypes.TEditCharCase.ecUpperCase; ecLowerCase = System.UITypes.TEditCharCase.ecLowerCase; type TEditCharCase = System.UITypes.TEditCharCase; So, some people seem to want to work around the SCOPEDENUMS.

Thanks, David. I had a look at the code of UITypes.pas, and there at the top, as brazen as anything, is {$SCOPEDENUMS ON} I learned something new. And only been doing Delphi since 1995.

Hi I have a TScrollBox that I am placing a number of "Cards" that are TFrame subclasses onto. As the number of cards increases, the performance of loading the list of cards initially is getting too long. Is there a way to delay loading these cards until they are scrolled into view? i.e. is there a way to trap the event of a card being shown in the scroll box?

Thanks Lars. I did actually try out a background thread, running the query, then creating the cards and populating them, but it didn't look good. The scroll bar and its contents remained inaccessible until the whole process had finished for some reason. But the 2 changes I ended up making, i.e. removing the override of SetBounds (which was to help with formating) and adding the override of PaintWindow, see above, has brought the speed of loading a couple of hundred to a reasonable value.

I have implemented Anders Melander's idea, and it works well. Part of the trick of getting it to work was that I needed to invalidate the cards explicitly to ensure that PaintWindow got called and that the Load method was called. Which was obvious, eventually. Here is the guts of the code that makes it work, from the abstract superclass of the cards: procedure TDBCard.SetKey(const Value: variant); begin fKey := Value; loaded := false; Invalidate; // Force call to Load in PaintWindow if card on screen end{ SetKey}; procedure TDBCard.PaintWindow(DC: HDC); begin inherited; if not loaded then begin loaded := true; list.DataQuery.Locate(list.KeyFieldName, key, []); Load(list.DataQuery); Color := list.CardColour(self, false); end{if}; end{ PaintWindow};

Thanks, Fr0sT.Brutal. We are using TJvTreeView and TTreeView in the project already, so if the current line I am following doesn't help, I will look into that.

Vincent: I don't think we will have a fixed height of the cards. They contain memo text, which may potentially be configurable or automatically expand.

I was overriding SetBounds in the card frame and it was getting called literally 10,000s of times and taking up most of the time. So, I have got rid of that. Here is some timing information, where I accumulate the time taken in various processes, and then display it in seconds, sorted by time in descending order. The second figure is the number of calls. There is overlap. UpdateCardList is the overall time. 1.935s is still a long time, but much better. Using SetBounds: 16:32:19 Update cards for HUN3 16:32:19 Record count = 202 16:32:24 Listing accumulated times: 16:32:24 * UpdateCardList: 4.569, 1 16:32:24 * SetBounds: 2.546, 95849 16:32:24 * Load cards from qry: 2.357, 1 16:32:24 * Create cards: 2.062, 1 Without SetBounds: 16:38:53 Update cards for HUN3 16:38:53 Record count = 202 16:38:55 Listing accumulated times: 16:38:55 * UpdateCardList: 1.935, 1 16:38:55 * Load cards from qry: 0.881, 1 16:38:55 * Create cards: 0.789, 1

Remy: There are 3 labels and a shape. The shape sits on the bottom to provide a diving line.

Thanks for that, Anders. I am open to a better solution, if you want to suggest one.