Requirements and pre-conditions:
- Chart series may contain different point types:
- First, let's call them 'automatic' - which may have been acquired by some logger process, in ordered, evenly spaced moments in time.
- Other type is 'manual', - meaning, that thesee may be acquired as a result of explicit user-to-device iteration during the same measurement session, as an automatic ones. These manual points usually have an arbitrary distributed x, and sometimes even y values.
- Chart series should draw automatic and manual points differently, while allowing these points to be iterated as a members of the same sequence.
When using boost framework, which I usually try to avoid, if possible, I further avoid using its binary libraries. Mainly because it's required to build these, and it's not as easy as it may seem.
First, you should build the boost build engine itself. My most recent attempt was with boost 1.66 + MSVC 2017. Needless to say, that I ran into quite usual showstopper. Boost could not compile b2 because it could not find a few C++ headers, and libraries. Following are necessary steps to perform to avoid these obstacles.
I started ESP8266 project, the first step was to support SDMMC over SPI. I have implemented SDMMC SPI interface years ago. The main challenge was to adapt it to new MCU core. After many attempts, it was up and running. Below are lessons learned.
Recently, I've complete my 'geshtalt' - migrate and release Windows FMX app, Ecolight-AP under MacOSX platform. And, by God, it was painful and hard, mainly due to EMB toolchain tried to fracture my butt on almost each final step.
The dehydrated knowledge here is crystallized two weeks of pain and swearing, and sweatting.
Problem starts reveling itself after all Debug stuff was successfully brushed on MAC, under PAServer session, and Release for App Store was created with Developer ID * certificates, which allow to install from signed local pkg.
Recently I've implemented lightweight header library to encapsulate interfacing with FTDI EVE chip, namely, FT800, in templated OO manner. It should compile in modern embedded x86/ARM toolchains, like ones Keil or C++ Builder have.
The idea is as follows - while your core framework provides standard IO bus interface, like mine esfwxe, via EseChannel templated abstract facade, the rest is done in modular manner by EVE library classes.
For the recent mobile FMX application development, I had a challenge, do not use any service from my full-featured cross-platform framework, to minimize application bloat, besides, FMX framework itself is rather big piece of cake.
One of the cornerstones is a I18N support which in my framework is based upon custom implementation of gettext. In current case, I decided to wrap I18N manager coode around FMX's TLang. As far as TLang may use, besides its binary stoarage, the plain text files as well, formatted as key=value pair.
Recently, I got to, as many many years ago, dive in Windows API, to implement a rather simple task. I needed to restrict an FMX-based application, namely its Windows-flavour target, to be single-instance, so any attempt to launch yet anther copy of its process would (try to) bring up the first running one.
Article explains how to use standard style elements to customize LookAndFeel of own GUI elements.