Hi @liminma8458. I did test the code you posted, and did not see the prompt to click somewhere (same as you), and do not initially understand why. But, I have never seen code put together that way while attempting to do what I suspect you were trying to do...which is OK, and expected when experimenting / testing. I am a little confused about the purpose of your code example, so I was not immediately sure how to suggest correcting it in a simple way. It looks like your intention may have been to first ask the user to select a circular part edge, then ask them to click somewhere in model space, then do something with those two pieces of data. But the Pick method is a Sub routine, instead of a Function, so it will not 'Return' anything to the 'calling routine'. Similarly, there is no secondary custom Function within the Class (besides the Pick method) like 'GetMouseClickLocation' which the user can call from the calling routine to get that data. Instead, you are trying to initiate additional, manual user interactions from the user from within the event handler, with no way of returning that data to the calling routine. I understand that this may simply be an 'exploratory' piece of code, so not really ready for direct use in a production related role, so you are likely just attempting to 'log' data. However, it is generally not a good idea to include MessageBox.Show() or MsgBox() codes directly within event handlers, and it is generally best to 'log' data using something like the iLogic 'Logger', or other call to a method defined outside of that event handler which invisibly records the data, then retrieve that data another way after the event. And yes, I do realize that is contradictory to the previous code example I posted. 😋 So, I would recommend a complete restructuring of the code. Convert the Pick method into a Function that returns something to a routine outside of that Class, which calls it to run. Then create another custom Function within that Class which can be called directly by a routine outside of that Class, and returns something to it. Then, create some additional Private variables within the Class (but not within any routine) to hold onto the values which you are interested in, that the event handlers provide. Within the event handlers, set the values of those Private variables. The custom Functions will then get the values of those private variables, and return them to the calling routine (outside of the Class). Then the calling routine (outside of the Class) can use the returned data however it wants, such as logging that data to the iLogic Log window, or showing it in a message, or using it as inputs for further purposes. Just some suggestions, but I think doing things that way will clarify it, help eliminate the issue you are seeing, and make it most dynamic / useful.
I will attach another example external iLogic rule I have, which may be helpful, but it also does not use a Class, so not the best match either. I do have several external rules containing Classes and Modules that I reference from other rules, but the 'related' ones are generally more elaborate, and primarily for selection purposes, instead of specifically for returning mouse click location/points. Some may include that data though Public Properties of the Class though, as a side bonus, because some selection events also return mouse position related data.
Wesley Crihfield

(Not an Autodesk Employee)