Addition to IndustrialStuff Package

[bobby100]

LGPL is OK for me too.

I took a look at your code, I like the idea, but there is a catch. Classic LCD dot-matrix displays are 5x7 (6x8 inclusive space) and newer displays are using 5x9 matrix. In your example you have variable width and total height of 16 dots.
If we go for language-specific letters (äöüßžćđ etc.) it will be hard to maintain the matrix without a fixed-width font where the language-specific letters are smaller (to make place for extra dots or lines). Also, the "g" in your example is going "under the line".

Any idea from your experience?
Implement an option to load external fonts (BMPs)?

[wp]

Classic LCD dot-matrix displays are 5x7 (6x8 inclusive space) and newer displays are using 5x9 matrix.

I was not aware that there is a specification for the size of the dot matrix. But then, is there also a specification for the character range? Maybe it goes only up to #127 (ASCII), and we could use the original code again.

[wp]

In the attachment I am sending a version of your code in which the AutoSize property is handled in the Lazarus way (CalculatePreferredSize) and LCLScaling is supported. The demo provided runs without installation of the component.

There is a minor issue when the CharSpace property is switched to ON: sometimes the black lines are drawn too far down by one pixel which overwrites the bevel. I am leaving this to you.

Returning to the code page issue, I think the character dot matrices should be handled in a more flexible way. Rather than in a static array, the character matrices should be stored in some kind of list (TFP(G)Map, in order to be able to search for a character), so that new characters can be added. Basically, this list should be filled by the 128 ASCII characters, and when more characters are needed there should be an Add function to add the dot matrix for the new character. In a final step, there could even be a component editor which opens a matrix grid in which the user can toggle the required pixels for the new character himself.

[bobby100]

In your code is AutoSize not working anymore. It sets the Minimum width (one char wide).

EDIT: I see, the LinesCount does not affect the frame size anymore.

EDIT 2: I am lost in your code, I can't find the error

[wp]

What are you doing? AutoSize is working in my demo. Or did you install the component (which I did not)?

[bobby100]

Installed, but I don't think the problem is there.

I am working on it. At the moment, changing LinesCount without AutoSize displays the dot matrix over the frame.

[sstvmaster]

And don't forget the 4x40 LCD character and there are different colors for background and chars.

In the attachment there are pictures, from an project.

[bobby100]

And don't forget the 4x40 LCD character and there are different colors for background and chars.

In the attachment there are pictures, from an project.

With this component, there are no limitations about number of chars.
The mentioned 5x7 and 5x9 are the dots/matrix inside one char.
If you take a look at the screenshot on the previous page, you will see that all the colors are settable (background, dot OFF and dot ON + Frame colors)

[wp]

At the moment, changing LinesCount without AutoSize displays the dot matrix over the frame.

Yes. I think the initial (non-autosized) height of the control is too small regarding the other initial parameters: 2 lines, 7 dots per line, each dot 4 pixels, 1 pixel spacing between the dots, 8 pixels for frame + 2 for bevel, in total: 89, but the height is only 76. Clearly this can be fixed by adjusting the initial height, but the issue remains: dots can be painted over the frame. This can be fixed by adding this to DrawDot before painting:

Code: Pascal  [Select][+][-]

1.   if (DotR.Top < FrameSize) or (DotR.Bottom > Height - FrameSize) then
2.     exit;
3.   if (DotR.Left < FrameSize) or (DotR.Right > Width - FrameSize) then
4.     exit;

In your old code this was not visible because you adjusted the controls size during painting (which I try to avoid by all means).

The attached version contains this code, as well as improvements of AutoSize.

[bobby100]

I came to the same solution

[bobby100]

I am thinking about rewriting the component as follows:
- no AutoSize
- ColCount and RowCount defines the Width and Height

That would be more LCD Screen alike. One can define the size of the screen in chars and there is no need of complicated calculating that can go wrong. There won't be different BoardWidth and BoardHeight for different component sizes etc.

What do you think?

[wp]

I am thinking about rewriting the component as follows:
- no AutoSize

I absolutely would like to keep it. The component looks much better when the dotted text fits into the control bounds. Is AutoSize still not functional? Tell me what's wrong.

- ColCount and RowCount defines the Width and Height
That would be more LCD Screen alike. One can define the size of the screen in chars and there is no need of complicated calculating that can go wrong. There won't be different BoardWidth and BoardHeight for different component sizes etc.

This is not the way all the other components are working. In the form designer you set the Width and Height as primary dimensions, everything else follows. And when you do it your way you have to do the same calculation, just in the other direction.

I am adding another version, now with dynamic creation of the character dot matrices and full support of UTF8 (basically). The character dots are now stored in a map class using the character as a key (which is a string because UTF-8 characters can consist of 4 bytes). Using the method AddDotMatrix the dots can be defined for any utf8 code point. The ASCII characters are already included, I copied the dot matrices from the TLCDLines_char unit which is not needed any more now. If you need more characters call AddDotMatrix for it - look at the last line of the LCD display in my demo, it contains the German umlauts which are defined exactly in this way.

This way it is also possible to enter characters for other matrix sizes (defined by your DotColsCount and DotRowsCount properties). This requires some typing, though... Probably I'll extend the feature by loading/saving dot matrices from/to file, maybe I'll also add a visual dot matrix designer.

BTW: Do we need the boolean 2D array DotsOn? After filling, it is not used anywhere else.

[bobby100]

DotsOn is used just for GetDotOn function. It is a function from the original TLCDLine component. I am asking myself if we need this function at all.
There is also the SetDotOn, which also does not make much sense anymore.

As for the rest of your additions - this is going better and better
I also have some additions, like predefined color schemes, modified the icon for components palette etc. I'll merge the code in the evening and post it here.
I have also extended the Demo to reflect all the additions.

btw. I've renamed the LinesCount to RowCount, and I've added ColCount. This way we can predefine the LCD screen size in characters.

[wp]

btw. I've renamed the LinesCount to RowCount, and I've added ColCount. This way we can predefine the LCD screen size in characters.

LinesCount referred to the lines of text. Is this the same with RowCount now? Or do you mean the number of dot rows? This would be confusing because ColCount certainly (?) is the number of dot columns.

And as I said in the other post, calculation of the control size from some internal parameters is against LCL conventions when AutoSize=false. Every user dropping a TLCLLines component on the form and adjusting the required size in the form designer will be very surprised when the size changes after changing the RowCount/ColCount properites. The size is only allowed to change when the user decides to override it by setting AutoSize to true, or Align to anything different from alNone, and maybe some more.

[avra]

There is one problem which I noticed looking at the code more carefully: unit LCDLines_char defines the pixel matrix for each character, but does this only for 255 characters. This means: the control is not ready for UTF-8, the Lazarus standard. And in fact scrolling down a bit, I see that the characters #192..#255 are russian cyrillic. I think this is a severe limitation.

Whatever changes you do, please leave the original fixed width 5x7 font (32..127 is enough) to be the default one, because people would mostly use that component to intentionally mimic standard 5x7 character based LCD displays. Adding different font, rendering to different size matrix, adding character proportionality, custom characters, font editor or support for unicode would be nice to have - but secondary features.

Also use unit names which do not conflict with pl components (if you did not take care of that already).