I have a menu popup object based on a container class. The visible property is always set to .F. for obvious reasons. Each member menu item object is based on a label class. I decided on this approach because, during design time, I wanted the ability to drag 'n drop menu items (from a class library) onto a popup container in addition to the ability to add them programatically at runtime. I'm too lazy to make a builder.

Now, the label object has custom properties (e.g. cBarKey, cBarSkipFor, etc.) and custom methods which affect a wrapper class for DEFINE BAR, ON BAR and so on. I use the label object's native visible property to determine whether or not the menu item is hidden or shown and it's _assign method to hide or show a referenced toolbar button.

I could have created a separate lMenuItemVisible property to accomplish the same thing, but I figured it would work with the native visible property and it does work with a simple one-line workaround.

I don't know if you read the entire thread, but the problem is that when the value and type of the parameter tlVisible is checked right after the "LPARAMETERS tlVisible" statement, it SOMETIMES returns a 0 and "N" instead of .T. or .F. and "L" like it should. I have run into similar problems with _assign methods of custom properties which hold object references. The funny thing is that the parameter will eventually recieve the correct value somewhere during the firing of the _assign method. Once again, this leads me to believe that there exists a very short wait state before the parameter recieves the correct value.

I am not the only one who has experienced this - someone (I forgot who) a few days ago reported the same problem with COM objects.

>I understand your points here....but the Visible Property on the control?? Tell me more about your example....