It occurred to me that more is hidden in the IDE than needs to be or would be optimal for Encrypted classes…
Shouldn’t we be able to see all Public properties,method signatures and enumns?
It sure would make using them easier to use without compromising the code.
What do others think?
They’re visible in autocomplete, and they should be documented by the developer anyway.
But it would still be convenient to see a list in the navigator, no? It would be a real memory aide when coding,
Documentation for seldom used 3rd party classes tends not to be handy all the time and autocomplete does not show method signatures…
In fact using autocomplete you would have to add a method and then mouseover it to see the signature… and you would still not see overloads that way.
I think there’s already a feature request for this
I can’t find it searching on encrypted
I’m certain I saw one from Thomas Tempelman but I can’t find one either
I suggest a work-around as I use it myself in my Zip classes:
Make a non-encrypted subclass of your encrypted class. That subclass can then call the encrypted functions (which are all “protected” instead of “public”). That way, the user can see even the source code of the public functions, and you can add documentation to each of them.
[quote=57168:@Thomas Tempelmann]I suggest a work-around as I use it myself in my Zip classes:
Make a non-encrypted subclass of your encrypted class. That subclass can then call the encrypted functions (which are all “protected” instead of “public”). That way, the user can see even the source code of the public functions, and you can add documentation to each of them.[/quote]
While that would be fine for something like zip cases, it would be a real pain for subclassed controls… Think listbox subclasses.
IMO the API for encrypted class should be exposed just as it is for internal classes who’s code we can’t access even if under the hood they are written in Xojo.