TWebCheckListBox error with TCheckBoxState

I put a TWebCheckListBox on my form, added some items, then when I compile it, I get this error:

[Error] frmMyForm.pas(2963): Incompatible types: got "WEBLib.CheckLst.TCheckBoxState" expected "WEBLib.StdCtrls.TCheckBoxState"

This is way past the end. in my source file, so it's in the javascript code.

The odd thing is I used the same control earlier and it worked, then I removed it.

I'm thinking that it's interacting with another unit. The TCheckBoxState enums are probably different definitions (ie, distinct types) even if they're the same.

Cannot reproduce

image

Can I ask to please first try to isolate something like this yourself and then provide either reproducible steps or a sample source project to reproduce.

As you can see, I've been finding all kinds of strange things lately, and many of them aren't showing up in isolation.

Regardless, it doesn't help that it works in isolation if it doesn't work in an actual use-case scenario since I can't get any more info to help diagnose the issue.

I'm sure you don't want to debug my whole app.

In this instance, I've seen issues like this in the past where there are identical enums for TCheckBoxState defined in different units, so the compiler considers them different and incompatible due to name scoping. In this case, they're inside of units where if I could cast the value, I would. The actual values are identical, in fact. But there's some kind of interaction going on that's raising compiler or run-time issues.

My primary goal is to get my app built, not ferret out underlying programming issues. I isolate it enough to the point where I either can or can't get it to work properly; if I can't, then I find another approach that works. It's one thing with the regular VCL and components allow me to debug stuff with the debugger. But when the compiler is raising errors in code that's past the end statement of my code and buried inside of some javascript code that I can't see, or I can't access at run-time with the debugger to inspect values, then I'm really not sure what to do. It's just acting weird at times and is as useful as a bike with a flat tire and no way to fix it at that point, so I toss it aside and try something else.

I appreciate all you guys do, and I really love the WEB Core technology. I especially appreciate that when you find bugs, you fix them and put out an update fairly quickly, rather than once a year.

I keep running into little things that seem to increase with frequency as I continue adding code to my app. When I can't isolate something, then I post a note for you guys. If you can't reproduce it, that just tells me it's deeper or more complex than one might expect, and I just find another approach. In the case of the Objects array in the grid not working, it was easy to work around it. With the timing issue between the dataset and the string grid, I just went back to the string grid and decided to implement a filter rather than sortable columns, and that's fine. The UI issues aren't a high priority for me right now. I've learned to not get too hung-up on specific approaches because there are usually multiple ways of realizing the same needs.

I really do appreciate your efforts. My primary goal is to keep pushing my app forward, not dwell on solving problems that are more of a time-sink than anything else. I need to get an MVP done so I can start raising some capital to continue focusing on getting this app more fully fleshed-out.

If we have no means to investigate what you experience, it is extremely hard to guess what is happening on your side. So, we need pointers to be able to reproduce this at least.

I understand that. All I can say is some things misbehave and show up in my app but work fine elsewhere or in isolation. I can send you screenshots, like for when the fonts and colors aren't showing up, but what good is it when they work in isolation? Some things are fairly cut-and-dried, like when I get an error by setting a property value in the Object Inspector and it's not there when I reset it. Others seem to be due to unit interactions and name scope issues that simply are not going to show up in isolation. In this case, since I can't debug into the code, there's not much I can do other than call them to your attention.

I have run into the issue with checkboxes before in a VCL app, and it's because some unit redefined the TCheckBoxState enum instead of referring to the one in the VCL unit. That causes name-scoping problems. Short of removing the duplicate, there needs to be a way to tell the compiler that they're the same so it won't complain. I don't know why it doesn't show up all the time, but that's the nature of things sometimes.

I scanned the full source code of the TMS WEB Core runtime framework and TCheckBoxState enum is declared only once in WEBLib.StdCtrls.pas.
Its enum values cbChecked, cbGrayed, cbUnchecked are only found in this context. There are no duplicates.

so what's the source of this error? I did not refer to either of them in my code. All I did was drop a TWebCheckListBox on the form.

[Error] frmMyForm.pas(2963): Incompatible types: got "WEBLib.CheckLst.TCheckBoxState" expected "WEBLib.StdCtrls.TCheckBoxState"

Do you use the latest release v2.1?

Just saw the announcement. Will give it a try.

Ok, it's not throwing that compiler error with V2.1.0.0. YAY!

1 Like

However ... I did find two more properties that are raising compiler errors:

  • CheckBoxPadding
  • State

[Error] frmMyForm(1205): identifier not found "State"

(past EOF)

There may be more!

These are being inherited from the inherited VCL component. Do they have to be explicitly reflected in the WebLib file?

Also, Checked[i] is always returning False, even when the box is checked. (That's how I found the error with State.)

Actually, when I assign it in code:

cklist.Checked[5] : True;

Then it works. It looks like the checkboxes are not being read correctly into the Checked array.

We've seen this regression due to introducing multi-column support.
We'll fix it and release an update asap.

1 Like

Two more missing properties (WEB Core v2.1.0.3)

ckbox.AllowGrayed set in Object Inspector raises compiler error at 'end.' line:

[Error] myForm(7394): identifier not found "AllowGrayed"

ckbox.Selected[n] := True

[Error] myForm(1582): identifier not found "Selected"

. . .
I'm guessing that if you find one of these properties missing in a given class, there are likely more...

We've applied a fix to avoid these compile errors.
Next update will have this fix.

Is this just some glitch somewhere? Or are the properties actually missing?

The UI features for highlighting things are far more limited than when using the VCL or FMX because a lot of stuff is suppressed or overridden by HTML / CSS tags and it's very opaque in terms of how to do some things simply. I keep finding UI display features that don't work at run-time even though they do often work in isolation. I'm just wanting to get my logic and flow down right now and deal with the "look and feel" later, but it has been quite challenging just to make certain things show up on the screen at run-time.

I'm guessing that some of the issues are because certain FNC components require Bootstrap to be loaded, and that's something that impacts EVERYTHING on the form in often subtle ways.

I absolutely LOVE what WEB Core offers, but I'm spending a lot more time than I like on minute UI display features that are not very important just to avoid an overly complex UI layout.

All of that aside, it's really exciting to see an idea that's been stuck in my head for years finally coming to life!

It is an oversight in the attempt to cover as much as possible VCL features in TMS WEB Core.
Our aim is simple:

  • match VCL as closely as possible
  • keeping typical browser characteristics in mind
  • not preventing use of features that are browser specific, like CSS for example ...
  • realize it will never be 100% as after all, the browser is quite different from the Windows OS

VCL is 28 years in the making, so wrapping most of the VCL in TMS WEB Core is a daunting task but step by step we'll get there.

2 Likes