ComponentModel.IContainer components

Josias formulated the question :
Mostrar la cita

Veo que cada form creado me crea este codigo en el form.designer.cs:

private System.ComponentModel.IContainer components = null;

Cual es el uso de eso?

Es para uso interno del diseñador visual, ni lo mires siquiera si no
quieres no poder ver la ficha en forma de diseño nunca más.

Microsoft Visual C++ MVP
==Mi blog sobre programación: http://geeks.ms/blogs/rfog
Mi blog sobre literatura: http://rfog.blogsome.com
Libros, ciencia ficción y programación

Un egoísta es una persona que piensa más en sí misma que en mí.

Quieres decir que los archivos nombrados "form.designer.cs" no formarán
parte del ejecutable final ?

Gracias RFOG.


"RFOG" escribió en el mensaje
news:
Mostrar la cita

Josias formulated the question :
Mostrar la cita

Veo que cada form creado me crea este codigo en el form.designer.cs:

private System.ComponentModel.IContainer components = null;

Cual es el uso de eso?

Es para uso interno del diseñador visual, ni lo mires siquiera si no
quieres no poder ver la ficha en forma de diseño nunca más.

Microsoft Visual C++ MVP
==> Mi blog sobre programación: http://geeks.ms/blogs/rfog
Mi blog sobre literatura: http://rfog.blogsome.com
Libros, ciencia ficción y programación
>
Un egoísta es una persona que piensa más en sí misma que en mí.

Sí que forman parte.

Ese código lo utiliza el diseñador visual para construir al vuelo el
aspecto visual de la ficha. El diseñador es un envoltorio a un objeto
http que es el que realmente construye la ficha dinámicamente a partir
de ese código. Eso en tiempo de diseño.

En tiempo de ejecución, ese código sirve para construir la ficha
real... que no es otra cosa que una especie de página web embebida
dentro de una ventana marco Win32.

Lo delicado del tema es que todo eso es muy delicado y se rompe con
sólo mirarlo, aunque fichas que no se ven en tiempo de diseño sí que
funcionan bien en tiempo de compilación.

Las versiones anteriores del Visual Studio tenían ese código dentro de
la propia clase que representa a la ficha, y era muy habitual que el
programador inexperto tocara ahí dentro de forma indebida (ya que era
una función más dentro del código fuente).

Tocar todo eso se puede, pero con conocimiento de causa y sabiendo
exactamente qué se hace y por qué (por ejemplo, a mi me ha pasado a
veces que el padre de un componente es uno que yo no quiero. Entro y lo
cambio a mano, ya que el diseñador se empeña en ponerme como padre al
primero, y entonces ya tengo al padre que quiero, y si en general es
una estructura compatible el diseñador ya no lo cambia).

Como cosa curiosa, los componentes se crean y ajustan de forma
diferente a si están ahí dentro o en un método normal. Crea una ficha
compleja con muchos controles, saca el código de ahí y ponlo en otro
lado. Verás cómo el resultado final es diferente, siendo el mismo
código.


Josias used his keyboard to write :
Mostrar la cita

Quieres decir que los archivos nombrados "form.designer.cs" no formarán parte
del ejecutable final ?

Gracias RFOG.


"RFOG" escribió en el mensaje
news:
Mostrar la cita

Josias formulated the question :
Mostrar la cita

Veo que cada form creado me crea este codigo en el form.designer.cs:

private System.ComponentModel.IContainer components = null;

Cual es el uso de eso?

Es para uso interno del diseñador visual, ni lo mires siquiera si no
quieres no poder ver la ficha en forma de diseño nunca más.

==>> Mi blog sobre programación: http://geeks.ms/blogs/rfog
Mi blog sobre literatura: http://rfog.blogsome.com
Libros, ciencia ficción y programación
>>
Un egoísta es una persona que piensa más en sí misma que en mí.

Microsoft Visual C++ MVP
==Mi blog sobre programación: http://geeks.ms/blogs/rfog
Mi blog sobre literatura: http://rfog.blogsome.com
Libros, ciencia ficción y programación

Un egoísta es una persona que piensa más en sí misma que en mí.

Gracias nuevamente. Yo realmente llegué allí porque sin querer le di un
doble click a un form y me creó un evento para el Load, el cual borré pero
el handler seguía activo y no me dejaba compilar, busqué y busqué hasta
encontrarlo en el designer.cs. Lo borré manualmente y me funcionó, luego me
puse a revisar las demas cosas que encontré allí a ver si entendía y por eso
puse el post.
Pero ya sé que debo ser mas cuidadoso y tratar de ni mirar para allá. Pero
no sé por qué me late que ese generador como que deberían mejorarlo o
bloquearlo para que uno no tenga la necesidad de entrar a modificarlo nunca,
ya que su único propósito parece ser simplemente inicializar las propiedades
que uno modifica en visualmente, o sea, una ayuda para no tener que escribir
ese código manualmente, más nada.
En otros lenguajes uno modifica esas propiedades igualmente de forma visual
pero nunca uno ve ese código generado, de hecho no habría necesidad de verlo
nunca ( a menos que el generador tenga algunos bugs).




"RFOG" escribió en el mensaje
news:
Mostrar la cita

Sí que forman parte.

Ese código lo utiliza el diseñador visual para construir al vuelo el
aspecto visual de la ficha. El diseñador es un envoltorio a un objeto http
que es el que realmente construye la ficha dinámicamente a partir de ese
código. Eso en tiempo de diseño.

En tiempo de ejecución, ese código sirve para construir la ficha real...
que no es otra cosa que una especie de página web embebida dentro de una
ventana marco Win32.

Lo delicado del tema es que todo eso es muy delicado y se rompe con sólo
mirarlo, aunque fichas que no se ven en tiempo de diseño sí que funcionan
bien en tiempo de compilación.

Las versiones anteriores del Visual Studio tenían ese código dentro de la
propia clase que representa a la ficha, y era muy habitual que el
programador inexperto tocara ahí dentro de forma indebida (ya que era una
función más dentro del código fuente).

Tocar todo eso se puede, pero con conocimiento de causa y sabiendo
exactamente qué se hace y por qué (por ejemplo, a mi me ha pasado a veces
que el padre de un componente es uno que yo no quiero. Entro y lo cambio a
mano, ya que el diseñador se empeña en ponerme como padre al primero, y
entonces ya tengo al padre que quiero, y si en general es una estructura
compatible el diseñador ya no lo cambia).

Como cosa curiosa, los componentes se crean y ajustan de forma diferente a
si están ahí dentro o en un método normal. Crea una ficha compleja con
muchos controles, saca el código de ahí y ponlo en otro lado. Verás cómo
el resultado final es diferente, siendo el mismo código.


Josias used his keyboard to write :
Mostrar la cita

Quieres decir que los archivos nombrados "form.designer.cs" no formarán
parte del ejecutable final ?

Gracias RFOG.


"RFOG" escribió en el mensaje
news:
Mostrar la cita

Josias formulated the question :
Mostrar la cita

Veo que cada form creado me crea este codigo en el form.designer.cs:

private System.ComponentModel.IContainer components = null;

Cual es el uso de eso?

Es para uso interno del diseñador visual, ni lo mires siquiera si no
quieres no poder ver la ficha en forma de diseño nunca más.

==>>> Mi blog sobre programación: http://geeks.ms/blogs/rfog
Mi blog sobre literatura: http://rfog.blogsome.com
Libros, ciencia ficción y programación
>>>
Un egoísta es una persona que piensa más en sí misma que en mí.

Microsoft Visual C++ MVP
==> Mi blog sobre programación: http://geeks.ms/blogs/rfog
Mi blog sobre literatura: http://rfog.blogsome.com
Libros, ciencia ficción y programación
>
Un egoísta es una persona que piensa más en sí misma que en mí.

Sigue abajo.

It happens that Josias formulated :
Mostrar la cita

Gracias nuevamente. Yo realmente llegué allí porque sin querer le di un doble
click a un form y me creó un evento para el Load, el cual borré pero el
handler seguía activo y no me dejaba compilar, busqué y busqué hasta
encontrarlo en el designer.cs. Lo borré manualmente y me funcionó, luego me
puse a revisar las demas cosas que encontré allí a ver si entendía y por eso
puse el post.

Sí, ese es otro de los motivos para meterse ahí dentro. De todos modos,
cuando te vuelva a pasar eso (que te pasará, ya que a veces el IDE
interpreta un click sencillo como uno doble), en el editor de código
presionas Ctrl-Z y si no pasa nada, te quitará el evento.

Mostrar la cita

Pero ya sé que debo ser mas cuidadoso y tratar de ni mirar para allá. Pero
no sé por qué me late que ese generador como que deberían mejorarlo o

Hay tantas cosas a mejorar en el IDE...

Mostrar la cita

bloquearlo para que uno no tenga la necesidad de entrar a modificarlo nunca,
ya que su único propósito parece ser simplemente inicializar las propiedades
que uno modifica en visualmente, o sea, una ayuda para no tener que escribir
ese código manualmente, más nada.
En otros lenguajes uno modifica esas propiedades igualmente de forma visual
pero nunca uno ve ese código generado, de hecho no habría necesidad de verlo
nunca ( a menos que el generador tenga algunos bugs).

Recuerdo el C++Builder y sus DFM, con Ctrl-F12 se convertía la ficha en
su equivalente en texto ASCII, y tenías que estropear mucho, pero
mucho, ese texto para que el diseñador dejara de funcionar.

Mostrar la cita

"RFOG" escribió en el mensaje
news:
Mostrar la cita

Sí que forman parte.

Ese código lo utiliza el diseñador visual para construir al vuelo el
aspecto visual de la ficha. El diseñador es un envoltorio a un objeto http
que es el que realmente construye la ficha dinámicamente a partir de ese
código. Eso en tiempo de diseño.

En tiempo de ejecución, ese código sirve para construir la ficha real...
que no es otra cosa que una especie de página web embebida dentro de una
ventana marco Win32.

Lo delicado del tema es que todo eso es muy delicado y se rompe con sólo
mirarlo, aunque fichas que no se ven en tiempo de diseño sí que funcionan
bien en tiempo de compilación.

Las versiones anteriores del Visual Studio tenían ese código dentro de la
propia clase que representa a la ficha, y era muy habitual que el
programador inexperto tocara ahí dentro de forma indebida (ya que era una
función más dentro del código fuente).

Tocar todo eso se puede, pero con conocimiento de causa y sabiendo
exactamente qué se hace y por qué (por ejemplo, a mi me ha pasado a veces
que el padre de un componente es uno que yo no quiero. Entro y lo cambio a
mano, ya que el diseñador se empeña en ponerme como padre al primero, y
entonces ya tengo al padre que quiero, y si en general es una estructura
compatible el diseñador ya no lo cambia).

Como cosa curiosa, los componentes se crean y ajustan de forma diferente a
si están ahí dentro o en un método normal. Crea una ficha compleja con
muchos controles, saca el código de ahí y ponlo en otro lado. Verás cómo el
resultado final es diferente, siendo el mismo código.


Josias used his keyboard to write :
Mostrar la cita

Quieres decir que los archivos nombrados "form.designer.cs" no formarán
parte del ejecutable final ?

Gracias RFOG.


"RFOG" escribió en el mensaje
news:
Mostrar la cita

Josias formulated the question :
Mostrar la cita

Veo que cada form creado me crea este codigo en el form.designer.cs:

private System.ComponentModel.IContainer components = null;

Cual es el uso de eso?

Es para uso interno del diseñador visual, ni lo mires siquiera si no
quieres no poder ver la ficha en forma de diseño nunca más.

==>>>> Mi blog sobre programación: http://geeks.ms/blogs/rfog
Mi blog sobre literatura: http://rfog.blogsome.com
Libros, ciencia ficción y programación
>>>>
Un egoísta es una persona que piensa más en sí misma que en mí.

==>> Mi blog sobre programación: http://geeks.ms/blogs/rfog
Mi blog sobre literatura: http://rfog.blogsome.com
Libros, ciencia ficción y programación
>>
Un egoísta es una persona que piensa más en sí misma que en mí.

Microsoft Visual C++ MVP
==Mi blog sobre programación: http://geeks.ms/blogs/rfog
Mi blog sobre literatura: http://rfog.blogsome.com
Libros, ciencia ficción y programación

Un egoísta es una persona que piensa más en sí misma que en mí.