Leaderboard

Please keep the profanity out. Delphi treats the constant in that statement as a set. See this.

Is this something that could match your needs? (untested) type QCL_WORD = SmallInt; t_bus_flags_w4 = record private data: QCL_WORD; function GetBit(Index: Integer): Boolean; procedure SetBit(Index: Integer; Value: Boolean); public property AlarmState: Boolean index 0 read GetBit write SetBit; property AlignmentState: Boolean index 1 read GetBit write SetBit; property InversionWait: Boolean index 2 read GetBit write SetBit; property OutOfMinBound: Boolean index 3 read GetBit write SetBit; property OutOfMaxBound: Boolean index 4 read GetBit write SetBit; property BelowSafetyHeight: Boolean index 5 read GetBit write SetBit; property InWorkingPos: Boolean index 6 read GetBit write SetBit; property LockingLatchState: Boolean index 7 read GetBit write SetBit; property BatteryWarning: Boolean index 8 read GetBit write SetBit; property BatteryAlarm: Boolean index 9 read GetBit write SetBit; property EVRState: Boolean index 10 read GetBit write SetBit; property LoadWeightZone: Byte index 11 read GetBit write SetBit; // 2 Bits property ColumnIsConsistent: Boolean index 13 read GetBit write SetBit; property LiftSetAcquireReq: Boolean index 14 read GetBit write SetBit; property MovementModeAbsolute: Boolean index 15 read GetBit write SetBit; end; implementation function t_bus_flags_w4.GetBit(Index: Integer): Boolean; begin Result := (data and (1 shl Index)) <> 0; end; procedure t_bus_flags_w4.SetBit(Index: Integer; Value: Boolean); begin if Value then data := data or (1 shl Index) else data := data and not (1 shl Index); end; // For 2-Bit-Property LoadWeightZone we need some special Getter and Setter function t_bus_flags_w4.GetLoadWeightZone: Byte; begin Result := (data shr 11) and 3; // Extract 2 Bits at Position 11 end; procedure t_bus_flags_w4.SetLoadWeightZone(Value: Byte); begin data := (data and not ($3 shl 11)) or ((Value and $3) shl 11); // Set 2 Bits at Position 11 end;

Visit the Indy page on Github and follow the Documentation link on the Wiki: https://github.com/IndySockets/Indy/wiki/Documentation

Maybe you could vote for an extension of @Jim McKeeth nice ColorPicker here.

Just check the link. There is OJson with "SAX" parsing as well.

I think you need more detail to attract candidates.

Hi Dave, that worked; thanks to you both.

@#ifdef Well , while i hate my life nowadays, and while just waiting for the blackout to brighten my day after only 3 hours of power, i tried to build you something Far from finished or polished, take it as example or prototype for what you can do with custom drawing, notice it is 10000 strings ! ListBoxAsStringList.zip My suggestion is to use VirtualTreeView, i couldn't find working copy of VTV on my PC now, and don't want to waste time downloading my encrypted archives from the cloud, so i used TListBox, it is simple easy and pretty straight forward. Notes: 1) i didn't use FillRec on the whole Listbox, while it is more efficient and faster to clear the background for all the items in one go, this will introduce an ugly flicker in the bottom half, do the system rendering which doesn't wait for anyone, by clearing the background for each item in time, we prevent this flicker, but will introduce small performance hit in overall drawing. 2) i disabled the selected item highlighting, because it does need little different approach, yet it is easy, just adjust the canvas brush color before the FillRect, this will be up to you to implement, as i said i don't have time and don't have the skins on the latest IDE versions to test and play with. 3) customize as you wish, like ... can you this ? ( there is no noticeable performance change) Hope that helps, also never underestimate Windows custom drawing, it is fucking blazing fast when done right.

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.

This is me

I've had to deal with several variations of that over time. Are there web-hooks in place that call the system to hand over each JSON packet? Or are they just dumped in chunks into a file, accessible by something like FTP? Or do you have to poll a system periodically for new data that has accumulated? 60k records per day isn't that big of a deal. And text is quite easy to compress, especially if there's a limited lexicon involved. Then there's the backing store, where it really depends on the total lifetime of that data, what the half-life of searches is (so you know when you can flush it out to secondary storage with low likelihood of needing the majority of it), and tuning the DB to optimize the queries that come in. In America, certain types of records need to be kept for a legally-defined minimum length of time, like 7 years for corporate and financial records. Most of it isn't ever looked at, but it needs to be kept online and backed-up in case of audits or lawsuits. Just figure out how to compress the crap out of it and stash it away so it's easy to retrieve when needed. The point is, your job is to make sure the recent data is quickly accessible, while the older data is on slower more massive drives but still accessible in a reasonable amount of time. (A subpoena for data might give a month or more to provide it, which should be plenty of time to deal with slower backing stores, or even mag tapes.) Do NOT try to make 100% of it accessible "instantly". The client might have some temporal requirements, but make sure they're reasonable.

If your concern is high memory usage, you can try OXml and use SAX parser. If your data is well structured, you can also use Delphi classes together with SAX parsing. This would dramatically reduce memory consumption compared to System.JSON. http://www.kluug.net/oxml.php However, your problem is not clear as stated earlier. You might want to add details.

Is this a one-time input of historical data or is more data available from the API every day? Perhaps it makes sense to write a completely separate program that operates in the background and just pulls data into a local database on a regular basis and then your user-facing program interacts with the local database?

Do you get a monolithic collection of json elements for the entire day, or do they arrive one by one? If monolithic, you could split it up and add each element to a queue. Is there a sequence of processing requirement? If not, you could have multiple parallell consumers of that queue.

This is still a work in progress, but I'm really happy with how it is going so far so I thought I would share... https://github.com/jimmckeeth/FMXColorDialog There are a few custom components in the dialog, and there is a palette code library, plus there is a new CMYK color record. Just fun project to mess around with on vacation. FMXColorDialogSample_PseA8aEaZC.mp4