Jump to content

The Code Captain

  • Content Count

  • Joined

  • Last visited

Community Reputation

1 Neutral

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. The Code Captain

    AutoNaming Events on TCollectionItem

    Thanks Remy - I'm looking into that now...
  2. The Code Captain

    Setting Events on TPersistent members

    Thanks @PeterBelow for the speedy response. The events are published. They are TNotifyEvent which is already handled on other objects. There is no 'Events' listed for the TPersistent derived objects (but there are for TCollectionItem derived objects and TComponent derived objects). I have tried using an editor for the TPersistent that changes how properties are enumerated (looking at how the default editor for TComponent works) but I still can't get the IDE to list any Events for something that's derived from TPersistent unless it's also derived from either TCollectionItem or TComponent.
  3. The Code Captain

    REST api: too much data

    You asked: Yes this is certainly possible. What you need is a 'Streaming Parser' that understands the lexical structure of the input (JSON) and fires appropriate events as a file is read, giving you the parsed data. We use this approach extensively and because it streams the file it can work with arbitrarily large input files. We also have code that sits on top of the parser that can use separate knowledge about the Delphi classes (either specifically coded or garnered with RTTI) to build Delphi Objects in real time from the JSON and then send each completed object to the application as they are read. And because they're delphi objects you could have a method in the object definition that then knows what to do with the data. So once you have the appropriate classes defined processing becomes as simple as instantiating the parser, configuring it and telling it parse the input stream. Each object is handed back to you and you can call a method on that object to process it. But of course you have to have the parser. The code we use is not currently released into the public domain, but if it's of interest and your client has budget I can ask if it can be licensed to you if that would help.
  4. In some of my TCollectionItem derived classes I override GetDisplayName so that the name shown in the IDE is meaningful for a user. This is very useful. Also when creating code for an event property on the TCollectionItem it uses that display name to name the method which is also very useful. In one of my TCollectionItem classes I am representing the definition of data attributes in a structured record. GetDisplayname was set to return the name of the attribute. To assist users who want to see an overall view of the definition without having to inspect each property at user request I changed the display name to the SQL definition for that attribute. This includes spaces, brackets and commas. This works and is very helpful for the users that requested it, but now the events are named based on the default display name (So instead of having something like CardCodeWriter I have something like TITIODataAttribute64Writer). Is there any way to supply a 'stub' for naming the events that's not the same as the result of the DisplayName?
  5. I write property and component editors for the classes I define so that they can be edited in the IDE. When editing an object in the IDE's object inspector a standard TPersistent only exposes properties which are not events. However, some TPersistents (notably anything deriving from TCollectionItem) do expose events. I would like to have events declared on TPersistent derived objects editable, but I cannot discover what I need to do in my property / component editors so that the IDE will expose them. I would very much appreciate a link to a sample component / property editor that does this. Thanks in advance!