Use your forum account to login.

LOGIN

TOP Contributors

  1. MikroElektronika Team (778 codes)
  2. Shawon Shahryiar (263 codes)
  3. Alcides Ramos Zambrano (172 codes)
  4. S P (67 codes)
  5. Dany (66 codes)
  6. MikroBUS.NET Team (35 codes)
  7. NART SCHINACKOW (34 codes)
  8. Armstrong Subero (27 codes)
  9. Roman Toropov (26 codes)
  10. FOURNET Olivier (25 codes)

Most Downloaded

  1. Timer Calculator (96891 times)
  2. FAT32 Library (51065 times)
  3. Network Ethernet Library (45500 times)
  4. USB Device Library (35602 times)
  5. Network WiFi Library (32614 times)
  6. FT800 Library (28636 times)
  7. GSM click (22014 times)
  8. PID Library (21794 times)
  9. microSD click (18235 times)
  10. GSM 2 click (15089 times)
Libstock prefers package manager

Package Manager

We strongly encourage users to use Package manager for sharing their code on Libstock website, because it boosts your efficiency and leaves the end user with no room for error. [more info]

< Back
Project

DynTFTCodeGen

Rating:

0

Author: VCC _

Last Updated: 2019-06-25

Category: Graphics & LCD

Downloaded: 12 times

Not followed.

License: MIT license  

DynTFTCodeGen is a tool, used for designing and generating initialization code and event handlers for DynTFT projects. It features a drawing board, an object inspector, a component palette and various dialog boxes for application and project level settings.

No Abuse Reported

Do you want to subscribe in order to receive notifications regarding "DynTFTCodeGen" changes.

Do you want to unsubscribe in order to stop receiving notifications regarding "DynTFTCodeGen" changes.

Do you want to report abuse regarding "DynTFTCodeGen".

  • Information
  • Comments (0)
Download

Download Project [823.36KB]

Version 1.0.0.0

DOWNLOAD LINK RELATED COMPILER CONTAINS
mikroPascal PRO for PIC32
  • lib
  • src
  • exa
  • hlp
  • hex
  • sch
  • pcb
  • doc

Project Blog

DynTFTCodeGen

DynTFTCodeGen

main application window

View full image

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) - see limitations below.

- 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.

- When manually removing component registration from a component, in Project Settings window, it automatically removes its dependencies, no matter they were set as dependencies of another component or not. The generated code should not be affected.

- 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 movemen 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.

- Many things are hardcoded, so there is no support for user-defined components. Although parts of the application allow customization, it was not implemented for adding new components.

- 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 have to be manually loaded when needed. Color themes will have to be managed separately for each DynTFT project.

- 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, ar 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.

- DynTFTCodeGen does not control the color theme used by a project. The color theme has to be manually included in a DynTFT project, using the DynTFTColorTheme.inc file.

- 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: As mentioned in the "Limitations" section, there is no proper support for that. The application statically depends on DynTFT to draw components. You can add your schema file to the "\Schemas" directory and add an entry to DynTFTCodeGenInstalledComponents.ini, but there would be no drawing for the new component. Automatic design-time calculations won't be possible either (e.g. see the ItemHeight property of a RadioGroup).

 

- 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 "HasVariabileInGUIObjects" 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.

 

- Q: Can I use "OnClickUser" event on components?

- A: At the moment of writing this, DynTFT library does not implement this event. Please use "OnMouseUpUser" event.

ALSO FROM THIS AUTHOR

RTCC_18FxxJ50 library

5

Library for accessing the PIC18FxxJ50 internal RTCC. The library should be compatible with other PICs with same RTCC.

[Learn More]

DynTFT Color Themes

0

DynTFT Color Themes are a dozen of different collections of inc files with color constants, usable by DynTFT components.

[Learn More]

PIC32 Memory Statistics

16

The purpose of this tool is to display a chart containing the memory allocation in a PIC32 project.

[Learn More]