SoloCodigo

...Me gustaria darle un click con el boton del medio (o rueda) en cualquier objeto de cualquier form de un proyecto y que me saliera un mensaje dicendome como se llama el objeto, tipo de objeto que es, form al que pertenece..etc.. o sea poder saber sus propiedades...

Esto es imposible...
Si yo creo un control Activex, que tiene pongamos 3 cajas de texto, 2 picturebox 2 label y 3 shapes, lo más que podrás encontrar es el nombre del control, ya no sabrás si yo he usado un label o si hice un 'print' directamente, tampoco sabrás si son realmente shapes o si son métodos gráficos y las cajas de texto o lo picturebox, pasa lo mismo, podrás sospechar que es esto o aquello pero nada más.
De igual forma todos los objetos que no tienen un controlador de ventana, tampoco podrás obtener info directamente.
Siempre puede haber controles no visibles, ocultos o suplantando a otros de modo que se puede afirmar que es imposible en la práctica, en teoría posible es posible, otra cosa es lo que necesites hacer para descubrirlo y se merece la pena el tiempo invertido. Esto es, si eres capaz de desemsamblar cualquier código y entenderlo perfectamente es en ese caso que digo que es teóricamente posible.

La razón de esto es que el código es privado, no es código libre por tanto no se han construído las herramientas específicamente para eso, sino que en lo posible contribuyen a que un autor aísle y pueda ocultar sus objetos. Además cualquier técnica con dicho fin es un delito en toda regla hoy por hoy. con esto quiero indicarte que te andes con ojo, limítate a controlar tu software o cualquiera que sea libre, no serías el primero que tiene problemas ni el último...

Para los demás podrás usar las API, por ejemplo FindWindows... y familia.

Tenía la duda de que pudieras ir por exactamente esa direcci´n, pero como no concretaste, generalcé.
No obstante hay una cosa que tienes que tener clara. Una vez que compiles tu programa en cierto modo es como si 'ya no fuera tuyo', es decir el programa no sabe que tu eres su autor aunque a ti te guste pensarlo, digamos que para eso es necesario que tú 'se lo digas'.

Esto es, lo más adecuado es que incluyas EN EL PROGRAMA la funcionalidad deseada para cada grupo de usuarios (perfil, configuracion, permisos), en conjunto con una base de datos donde cada uno hace login para acceder al programa. Dicho de otro modo al iniciar el programa te solicita login, si eres el administrador te muestra un formulario extra, o un menú extra del que se accede a un formulario extra, en ese formulario extra, estarían las funcionalidades de administración (consola, panel de administrador), donde tu señalas que cosas están activas y cuales no para cada grupo de usuarios (perfil, configuración,permisos). Esos cambios se deberían guardar a la base de datos, luego cuando se loguee cualquier otro usuario el programa determina a que grupo de usuarios pertenece y en base a ello habilitará o no las funcionalidades que tu le adjudicaste.

Tal como lo quieres hacer tiene varios inconvenientes:
   El programa una vez publicado no contempla que tu eres quien lo creó, tampoco contempla el caso de ser un administrador o otro tipo de usuario si el programa no fué diseñado así, es decir te dejará usarlo o no, pero no activará tal o cual funcionalidad... si te peleas contra el 'ActiveDirectory' si podrías hacerlo (también requiere ser diseñado para usarse conjunto a ello), pero el cacao mental para controlarlo es muy superior frente a lo descrito en el párrafo anterior.
   Aunque 'leas' que un control es de un tipo u otro, la funcionalidad de un programa no está prevista para que se activen o desactiven controles alegremente, sino funcionalidades, una funcionalidad son un puñado de métodos unido a unos controles, eso significa que aunque un control esté deshabilitado podría seguirse usando por una función, o al revés aunque el control esté desactivado una función es accesible ya que las funciones no tienen una interfaz gráfica (sólo es código), lo que requiere que se diseñe una opción gráfica para acceder o no a dicha función.

Con un sencillo ejemplo lo entenderás mejor, supongamos una calculadora, y supongamos 3 usuarios, un niño pequeño que sólo tendrá acceso a las 4 operaciones fundamentales, un usuario normal que tiene acceso a la 'calculadora' estándar y un usuario experto que tiene acceso a la 'calculadora científica'. En este caso, la calculadora puede estár perfectamente definida cada una de sus funcionalidades con los botones que sirven para cada utilidad, pero porque ya se ha previsto durante el diseño de esa manera, no obstante en vez de tener 120 botones y 93 deshabilitados por razones de 'usuario' es mejor reordenar los botones en 3 interfaces distintas (perfiles, configuraciones) una para cada tipo de usuario, cada interfaz gráfica sólo requiere mostrar los botones deseados y reubicarlos de forma 'armoniosa' y útil, los no mostrados son además deshabilitados, sino aunque no se vean todavía serían accesibles con la tecla de tabulación... No queda nada elegante mostrar 120 botones de los cuales nunca tendré acceso a a 80, es mejor que ni siquiera aparezcan se desvanecen las dudas y se evitan ciertas 'intrigas' por ver si se puede 'piratear'...

Ahora observa como aunque entre el usuario niño, si estoy usando la funcionalidad de numeración decimal, las teclas 'A,B,C,D,E' de la numeración hexadecimal están deshabilitadas, todas esas teclas junto a las teclas '0-9' , forman parte de la funcionanildad numérica hexadecimal, por tanto no sería muy útil por ejemplo desactivar una a una cada tecla, o desactivar sólo la 'A', porque aunque no pudiera pulsar la A, siempre podría poner 10 en decimal y luego pulsar al cambio hexadecimal con lo que aparecería la 'A' sin haberla pulsado. Estonces puedes comprender que acceso a una funcionalidad, no implica necesariamente deshabilitar un control. Supongamos que deshabilitas la tecla de cambio de numeración y lo fijas para que no sea posible otra excepto la decimal. ...anular la funcionalidad hexadecimal requerírá también desactivar las teclas ligadas a ello, es decir las teclas antedichas 'A...E', de lo contrario aunque no tenga acceso a uno numérico hexadecimal, se producirían errores si el acceso decimal me dejara usar los botnes 'A,B...E'. Cada funcionelidad está ligada a métodos y controles y un control puede participar en más de una funcionalidad.

En el caso de una calculadora sería más o menos fácil entender que teclas van con una funcionalidad y cuales no, pero además sucede que una misma tecla forma parte de diferente funcuionalidad, si deshabilitamos la tecla lo estamos deshabilitando para que no se use para aquello que queremos evitar pero también para el resto de funciones.... además el caso podría a ser extremadamente complejo según el diseño del programa.

Entonces el modo adecuado de proceder es como te indicaba con CONFIGURACIONES (perfiles, permisos), para establecer configuraciones lo mejor es proveer un formulario aparte (de administración) a la que sólo tiene acceso para ver y modificar el administrador y para ver quizás otro administrador con menos privilegios. en dicho formulario estableces que grupos de usuarios hay y cuales son las funcionalidades a las que tiene acceso. Cuando el usuario se loguea se recoge de la base de datos una estructura (en realidad una tabla) con los permisos que tiene, antes de que aparezca el formulario deseado, durante la carga del mismo se deshabilitan y/u ocultan los botones  de acuerdo a la configuración del perfil de permisos, sin embargo ahora se supone que el diseño de permisos está establecido de de forma coherente, y no caóticamente habilitando y deshabilitando botones sin ton ni son.... Esto sólo en la 'consola del administrador'...
Y definitivamente como te indico el programa ya debe estar diseñado específicamente para atender cada caso.

Piensa que aunque tengas 700 controles no necesitas deshabilitar uno a uno, sino meterlos todos los deseados en colecciones, por ejemplo: controles disponibles para todos los perfiles en una colección, controles para un perfil concreto en otra colección, controles para un permiso concreto en otra colección, entonces habilitar un perfil es tener una función a la que se le pasa una estructura de permisos, en esa función se invoca a otra función que recibe como parámetro ua colección y el permiso (habilitar deshabilitar), la función lo que hace es recorrer toda la colección y poner cada control al estado que indica el parámetro. Esto es rápido y sencillo. El panel del administrador lo que hace es indicar cuales son las colecciones que tienes (cada formulario y cada contenedor tiene una colección controls), crear y eliminar nuevas colecciones con referencia a un nuevo permiso que crees y habilites y asignar los controles a una u otra colección, finalmente debes guardar la colección y los permisos en una base de datos, pero además debes exponer las funciones y métodos que deben ser controladas, de tal modo que si un control está vinculado a una función activar o desactivar el control hace lo propio con la función y viceversa.

Si por ejemplo reúnes diferentes controles en colecciones en base a permisos, crear y utilizar un perfil, indica el estado para ese permiso activado, desactivado, el procedimiento siempre será el mismo loguear al usuario extraer la tabla de permisos del usuario y filtrar los controles cuando se carga un formulario de acuerdo a los permisos (recorriendo las colecciones de controles que están asignada con cada permiso y activando o activando según indica el estado del permiso),

Si has captado la idea trata de resumirlo aquí mismo y exponer claramente los pasos, luego repaso y corrijo tus dudas... punto por punto. Después de esto haría una pequeña aplicación exponiendo un ejemplo que podrías leer a nivel de código para finiquitar tus dudas.