Hi BhavBhuti,

The problems aren't silly and I'm happy to try and help, but I will be heading off to climb some mountains in the Italian Alps on Friday, so it would be nice to sort this out before then.

Confession time, I don't use frameworks and at the risk of starting a pointless argument I have to say I find them too constraining. Worse still, in my youth I used to enjoy programming in assembler. Still it takes all sorts. As a result my suggestions may not be feasible with the setup you have, but I would be surprised if they couldn't be implemented.

In your code, I can't understand why you want to repeatedly create and destroy the selection object. Creating and destroying objects takes up processor time and slows the application down (a teeny bit).

I think it is best if you just create the selection object once, at program startup, as in my last posting. You can then make it visible or hidden when and as you need it. The object just hangs around in memory waiting for you to use it. At this point it could be argued that it is now consuming valuable memory resources, when not in use, but I'm feeling a bit deaf at the moment.

This approach allows you to remove the CLEAR EVENTS from the Destroy of the Selection object, which had earlier been interfering with your program's READ EVENTS.

In your framework init code, you should be able to create the object once, then from your program's menu set its visible property to .T. whenever you want to make a selection. On selection the object sets its visible property back to .F.

Hope this helps and I haven't misunderstood what is happening.

Alan