New in v2.0.0.1:
- Updated plugins, to support cropped text and custom icons on the DynTFTItems component. When generating code for existing projects, which contain Items, ListBoxes or ComboBoxes, make sure their VisibleIcons property is updated from ObjectInspector.
- Added a Remote System plugin, which allows plugin development, without closing DynTFTCodeGen (except when adding/removing components). It is built on the existing System plugin, but it's split in two parts, connected through TCP/IP (plugin + RemoteSystem server). Each of the two parts contains both a client and a server module, to allow initiating drawing requests from both sides. Unfortunately, there are still some race conditions, which prevent this plugin from properly repainting components on every refresh.
  (The Linux build of the plugin, DynTFTCGRemoteSystemServer, is a 32-bit build and will require libgtk2.0-0:i386 package to be installed)
  Because DynTFTCodeGen backs up the default color theme into plugin's memory, the server part of the plugin (DynTFTCGRemoteSystemServer.exe or DynTFTCGRemoteSystemServer) must already be running at DynTFTCodeGen startup. Otherwise, most color constants will default to 0.
- Minor improvements on the Plugin Manager window.

- New in v2.0:
  - Components are moved to plugins, so they can be customized. Also, new components can be installed. For backward compatibility, new components should be created in other plugins.
  - Component fixes do not require releasing a new version of DynTFTCodeGen anymore. Since they are defined in plugins, only the plugins have to be recompiled.
  - DynTFTCodeGen is now able to open mixed (i.e. concatenated) color themes. These themes can have components which specifically target various plugins. (Details in .dyncol files of the color themes).
  - Component schema files belong to plugins now, instead of DynTFTCodeGen. Every plugin should have a directory near it with schema files for all its exported components.
  - Fixed the local editor on ObjectInspector, for ActiveFont property, when the property belongs to a subcomponent.

- Known issues / Limitations in v2.0:
  - Some projects may still depend on the number and order of the installed components (which depend on the order of installed plugins). If this order does not match, those projects cannot be read.
  - Although DynTFTCodeGen allows loading plugins, which export components with overlapping names (same component names across plugins), it saves projects using the old format. This will cause the components to be used from the first installed plugin only, when opening the project.
  - Component registration may be wrong or reset if opening a project, which was saved in previous version of DynTFTCodeGen. This is the case when the order of installed components does not match the order of when the file was saved. Please manually verify from Project Settings.
  - Although DynTFTCodeGen can open mixed color themes, DynTFTColorThemeGen is not yet ready for it. For now, themes have to be individually edited using DynTFTColorThemeGen, then manually merged (mixed) using a text editor.
  - When recompiling, plugins may sometimes be wrongly linked. This may cause access violations in plugins, which are displayed on components from DynTFTCodeGen's DrawingBoard. If that's the case, please do a full rebuild of those plugins.

- Possible issues in v2.0:
  - There may still be untested features, resulting in regressions.
  - To overcome the limitation of having the components in the same order as they were when a project was saved, the components are now read from project, based on the order of installed components. If major bugs are found because of this and the project is not usable, please revert to an old version of DynTFTCodeGen (without plugins).

Features

- Component properties can be edited using an object inspector. Event handlers are also included.

- Components can be locked, so their position and size can't be accidentally changed. When a component is locked, it can't be dragged/moved or resized on the drawing board.

- Ability to preview the design using a color theme (.dyncol file)

- Components are organized using screens, so they wouldn't be displayed all at once.

- Components belonging to a particular screen, can be set to be visually persisted across all screens (design-time only).

- Ability to drop on the drawing board, components which are usually part of other components, that do not work on their own: Items, RadioButton, TabButton, KeyButton, MessageBox.

- Component properties are organized in two categories: Runtime and Designtime. Runtime properties are found in component type definition, while Designtime ones are used for editing only.

Known issues

- Components are flickering when moved or resized on the drawing board.

- Can't properly move/resize a component while scrolling with the mouse wheel

- On particular OS setups, the application can display "Cannot focus a disabled or invisible window." after starting.

- Sometimes, after closing the application, it can keep a CPU core to the maximum (not sure how to reproduce). This was encountered a few times during development, so it might be related to test builds only.

- Small memory leaks. As a rough estimate, opening a project with 512 panels, the application is reported to use 12.5-12.8MB in TaskManager (2.5MB, started fresh, without any project). After a few cut-paste operations of all panels, the memory usage increases to 18MB (about 1KB / cut-paste of all panels). Since this is not much when working with a "normal-sized" project, in-depth analysis was deferred to a future version.

Features, not bugs

Some parts of the application may behave a bit differently than expected. This is by design, either to optimize operations or to keep implementations simpler. Others might be considered incomplete implementations.

- Copying components using keyboard shortcuts, requires the drawing board to be focused (mouse over drawing board). This depends also on a setting to automatically focus the drawing board when being hovered with the mouse. If that setting is off, users will have to click on one or more components to focus the drawing board, prior to the copy operation.

- Ctrl-A selects only those components from current screen. Use Ctrl-Shift-A for all screens.

- Components are hidden while pasting or selecting (for a faster operation). Users may notice that components are hidden for a few milliseconds. Pasting requires new components to be created, so setting their position and size would require additional painting operations. Being hidden, some of these operations are skipped.

- Copy-paste operations do not include screen size. Only components are copied.

- When pasting components (all copied from the same screen), they are pasted in the current screen, regardless of their ScreenIndex property.

- When dragging multiple selected components, towards 0 (either left or top), their relative position changes as they are constrained to the visible area. Since there is no undo operation, this can be cancelled by right-clicking while the left mouse button is still down.

- Property values, which depend on compiler directives, are displayed in red in ObjectInspector

- When starting to drag a component, the component won't move for the first 5px (configurable) of mouse movement in any direction. This is to prevent accidental moving on MouseDown. Hold Alt key while dragging, to temporarily disable this feature.

Limitations

- There is no information about used memory of the DynTFT components, at design time. Please use a simulator, as provided in DynTFT examples.

- There is no live drawing for VirtualKeyboard (colors are set to default). It has fixed size. This is because of the internal complexity of this component. Since there is no pointer to each key button, the keyboard relies on the internal structure of DynTFT to keep track of all its buttons. DynTFTCodeGen does not use that structure, so it would require a different mechanism of keeping track of all these buttons.

- No Unicode support.

- No zoom support.

- No undo/redo support.

- Although Object Inspector and Component Palette can be resized, they can't be moved.

- Runtime Z order may not always match design-time Z order. Most of the time, components should not be overlapped. More than that, there are some components (e.g. DynTFTComboBox, which bring some of their parts to front, on run time, changing design-time Z order).

- Components can only be brought to front or sent to back.

- Not all constants are available in ObjectInspector as choices for a particular property. Constants are displayed based on their data type.

- Some enum-like properties (e.g. ArrowDir, Direction, Orientation etc) are allowed to be set to all available constants of a component.

- Displayed components are not transparent, so if overlapping, they may look a bit different on simulator and hardware.

- Schema files are not validated, so expect crashes or bugs if manually edited.

- Components don't snap to a grid or to each other. Use the "Lock" property to avoid moving them accidentally.

- Property values are not displayed in bold in ObjectInspector, if different than defaults.

- Adding new tabs to a page control, or new radio buttons to a radio group can be done only by using their "Items" property. There is no special pop-up menu for these components.

- Unknown component properties are ignored when loading a project. They are discarded on save. The same for copy-paste. This may be encountered when having two or more instances of DynTFTCodeGen, installed in multiple different locations, each with its own set of different schema files.

- Changing direction/orientation of a ScrollBar, TrackBar or ProgressBar, does not automatically swap their Width and Height values.

- Switching from one component to another on the DrawingBoard does not automatically select the last focused property in ObjectInspector.

- The icon order in component Palette is hardcoded. Icons are also built-in.

- Colors from color themes, are not embedded in projects. They can be "mentioned" in projects.

- When pasting components leads to duplicate names, only the object names are modified. Captions are kept.

- When pasting components from multiple screens, the current screen is not changed, but the paste operation succeeds.

- No built-in simulator. Users will have to manually rebuild their project simulators after every code generation.

- Double clicking on properties in ObjectInspector, is not implemented for all property types.

- Double clicking on events in ObjectInspector starts a 200ms timer to automatically create a new handler. The double click action has to be faster than 200ms, to create the handler.

- Double clicking on a component does not generate an event handler. Use the ObjectInspector.

- No support for vertical text orientation. This is a limitation of DynTFT library.

- The height of items (see ItemHeight property) of the Items component, has to be manually adjusted according to used font. The same for button height on PageControl.

- Empty RadioGroups and PageControls will generate uncompilable code. Always have at least one button. If manually creating buttons at run time is desired, either use a RadioGroup/PageControl with a button and remove it dynamically, or manually create the RadioGroup/PageControl at run time.

- Project file name is added to generated files, to warn users about overwriting with a different project. If there are two projects with the same name in different locations, no warning is given. Also, the project name is verified from DynTFTGUI.pas only.

- Handler names are verified as case sensitive. If renamed to a different case, they are added as new handlers. Old handler headers will have to be manually removed. The same for parameter list of these handlers, which have to match definitions from Schema files. If they don't match, new ones are created.

- Unused/unassigned event handlers are removed from a DynTFTCodeGen project, only when closing the project. If they appear in generated code, they have to be manually removed.

- Handler implementation is added based on new added handlers with regard to existing handler headers in the generated file. If their implementation is manually removed, the new implementation is re-added, only if adding new handlers or removing their headers from the interface section of the DynTFTHandles.pas unit.

- Properties are organized into Runtime and Designtime categories in ObjectInspector. They are sorted by name in each category. That can't be changed.

- Some property names are hardcoded into application, like "ObjectName", "ScreenIndex", "Left", "Top", "Width", "Height", "CreatedAtStartup", "HasVariableInGUIObjects", "Locked", "ActiveFont" etc. Do not rename them in schema files, as the application will become unusable.

- Not all properties / data types are constrained in ObjectInspector. Be careful about what you input. Integer properties accept string values, to allow user-defined constants to be used. This is to allow assigning variables, constants, functions etc to a property, at runtime, which DynTFTCodeGen should not know about. However, properties like "ObjectName", "ScreenIndex", "Left", "Top", "Width", "Height" are required by DynTFTCodeGen, and have to be assigned to constants at designtime.

- In ObjectInspector, properties of array type (e.g. "Strings", "Items^.String", "AllButtonsWidth" etc) display their values in a single line, without any blank between values. An items editor is available to edit such properties.

- Object names are not validated against existing event handler names or viceversa. Name collisions will be detected on compiling the DynTFT project.

- When the template files are changed (*.txt files from the OutputParts directory), for the handlers file, the changes have to be manually applied. This is because DynTFTCodeGen either generates this file from scratch or adds code to it, but does not keep it in sync with template files.

- When there are components for which no property is set and all of them are configured to have no variable in DynTFTGUIObjects file, a local variable is generated and left unused after assignment. This will cause a compiler notification about unused variables. The limitation comes from the Schema files, which only support one type of implementation, assuming that components will be customized and at least one property will have a value different than default.

- Although DynTFTCodeGen projects contain the list of available components, if loading a project in a DynTFTCodeGen instance, which has a different list of available components, the project may not be loaded properly.

- DynTFTCodeGen can work with up to 255 screens and will generate code for them. It does not take into account the number of screens the library supports. See CDynTFTMaxComponentsContainer constant from DynTFTTypes.pas unit.

- The colors used at design-time are 32-bit only. The code generator handles both 32-bit and 16-bit colors when generating output files. See Project Settings for options.

- There is no option to limit the number of recent files. If really needed, the DynTFTCodeGen.ini file can be edited using a text editor.

- DynTFTCodeGen does not manage DynTFT projects. Compiler directives, like DynTFTFontSupport have to be manually added to projects (Project Settings in Delphi/FreePascal and .pld files in mikroPascal). The same for extra units, e.g.: ExternalResources.pas, added in DynTFTGUIAdditionalUnits.inc.

FAQ:

- Q: Does DynTFTCodeGen backup the projects it saves?

- A: No, it does not backup projects. It is recommended to use a version control software and keep track of as many changes as possible. It does create backups of the generated DynTFTHandlers.pas file, because it is expected that users edit this file using a source code editor.

- Q: When I copy the value of a property from one component, then paste it to another component, why does it set its value to "[SelectionInfo]"?

- A: The "[SelectionInfo]" string is part of the copy-paste format content when copying components. This indicates that a component was focused when pressing Ctrl-C, not the Object Inspector. Make sure not to move the mouse cursor outside Object Inspector when copying a property value. Also, see Application Settings for options about focusing the drawing board.

- Q: How do I add my custom component to the application?

- A: Start by duplicating the "Remote System" plugin source code. It is the most flexible of all plugins, although the most complex. It allows rebuilding its server part without restarting DynTFTCodeGen. Make sure you rename both the new project and its exported components. After that, the new plugin can be installed in DynTFTCodeGen. Create a new component, by copying one of the existing system components (e.g. DynTFTButton). Make sure you don't use the "DynTFT" prefix on the new component, to avoid name collisions. Continue by modifying the new plugin (mostly component name) and make sure you include the newly created component. Recompile both parts of the plugin (dll and exe) and restart DynTFTCodeGen. The new component should be usable on the drawing board. At this point, the component should be editable from its source code and only the server part (exe) of the plugin will required recompilation/restart. A simple resize or setting a property value for the new component, from DynTFTCodeGen, will trigger a repaint operation. There is plenty of source code from other components, to be used as examples. Also, don't forget to create a new icon and update the image list from the plugin.

- Q: Why the property for the name of a component is called "ObjectName" and not "Name"?

- A: "Name", if implemented, should be a runtime property and it wouldn't be practical to ensure it is unique. It may be useful mostly for debugging.

- Q: Why the property for font is "ActiveFont" and not simply "Font"?

- A: ActiveFont is a pointer to font information. It is unpractical to store the entire description of a font in a property, so a different name makes more sense.

- Q: Out of the four generated files, which one can be manually edited using an external editor?

- A: Only DynTFTHandlers.pas can be manually edited, so users can add code to the pregenerated handlers. The other three files (DynTFTGUI.pas, DynTFTGUIObjects.pas and DynTFTFonts.pas) are completely regenerated.

- Q: How to swap two screens or move a screen to a different index?

- A: Hover the tab buttons of the list of screens with the mouse, hold the Ctrl key and start scrolling with the mouse wheel.

- Q: Can the settings of the default font be changed?

- A: Yes, just add it to the list in the Project Setting dialog, then change the settings. This is useful when using a custom TFT library.

- Q: If the generated code is smaller and less RAM is used when the "HasVariabileInGUIObjects" property is set to false for most components, why isn't this the default value?

- A: It is easier for users to find a component by its object name. For components which generate an event and have an assigned event handler, the Sender parameter of the handler can be used to get a pointer to that component. They can have the "HasVariableInGUIObjects" property set to False. It requires typecasting though.

- Q: Where should I look first, if something behaves different than expected?

- A: There are general application settings and project-level settings, found under the Tools menu. In addition to that, there are screen options under the Screens pop-up menu. There are also various design-time component properties, which configure component behavior. Hints will pop up all over the application. Unfortunately, not all features are configurable.

- Q: What should I do if I find a bug?

- A: Before reporting a bug, please see if it is already mentioned in one of the "Known issues", "Features, not bugs" or "Limitations" sections above. Do not send me or publicly post projects (*.dyntftcg files), as they might contain information you don't want to give away. If a minimal project is required to report a bug, please open it using a text editor, and look for stuff you might want to remove. When reporting a bug, it is desired to mention the steps used to reproduce the bug, by having the first step as "open the application", followed by "click here", "click there"‑like steps. Also, if a project is already corrupt (either by DynTFTCodeGen or manually edited using a text editor), it has no value in reproducing a bug, because the application is not designed to handle corruptions. However, it is very useful to have the steps about how a good project can be corrupted by the application. If you are editing schema files, bug reports may have little value, because these are not validated, so the application may not work properly.

- Q: Can I use an already existing DynTFTHandlers.pas file in a project in which DynTFTCodeGen generates this file?

- A: Yes, if the code generation symbols are manually added on functions/procedures (also notice the difference //CodegenSym:header vs. //CodegenSym:handler) and the headers match the string format that comes from schema files. Probably, the easiest way is to let DynTFTCodeGen generate an empty file, then you can add your code to it.