"Inspector Behavior" and Inspector behavior

I find it appalling that

  1. Global enumerations defined in modules are not available in the class “Inspector Behavior” window.
  2. Enumerations defined in the class “Inspector Behavior” window are not available to the application.
  3. There is no error-checking (or auto-complete) for constants entered in the Inspector. I can enter “#kFoo” in the inspector and the compiler doesn’t tell me that kFoo doesn’t exist, it just treats “#kFoo” as a literal.

Am I asking for too much?

Enumerations have to exist independently of the project for the system to work because the e um definition is stored with the property.

Same as #1 but the inverse

That’s a tricky one. I remember talking about this with the other engineers at one point and the question that comes up is “what happens is you want a hash at the front of your string literal?” What you’re proposing would cause errors every time if it wasn’t a constant, whether right then when you typed it or every time you compiled.

IMHO they probably could make that into a Warning, such that if you did this and checked the project, you’d get a warning, but I find that most people ignore warnings until they become errors.

I’m not quite buying that this is insurmountable. OK, store the enumeration in the property if that’s required, but make it a copy (alias?) of the module-defined one.

I can see that this might be more problematic, but if #1 was implemented, #2 wouldn’t be so necessary.

Really? Somehow Xojo figured out what to do if you want an ampersand in a button’s caption…

Well, yeah, that’s the idea :slight_smile:

Seems a perfectly reasonable choice. It fits in with the && pattern, as you say. I would be happy to sign on to a feature request for this. The value of spotting bad constants does seem to out weigh any inconvinience.

1 Like

Right up until you need something that’s not a constant with a hash at the front and then you find that you can’t compile your project.

This is one of those areas that could suddenly cause a users project to stop compiling with a new version of the product if they’d already been using them… and they’re used all over the place on the web so the IDE needs to be able to honor that.

Yes, the idea was that #value would always be treated as a constant. If value wasn’t defined then an error would be raised. If you wanted a literal #value then you must use ##value.

But it also brings with it the possibility that you have spotted a whole range of errors that have previously been hidden from the developer. One session of adding ## where required and you’re done.

1 Like

That’s the OS, not Xojo.

Not on a Mac.

-Karen

1 Like

Unless you are writing all your code in an earlier Xojo version and want to build with a more current one.

Then it’s a bit more annoying if existing code breaks in a newer version since you need to fix it in the earlier one, finding a way that works with both/all.

That said: definitely possible should this request happen to be implemented.

To which an obvious solution presents itself. Use a constant and put a #value in it. Problem solved in any version.

In fact you could forget about ## in the inspector at all. If # always means a constant, and generates an error if absent. If you want a literal # simply put it in the constant.

1 Like

Actually not. The compiler will still see it as a constant.

In which case we’re back to ##.

I’m out.