¿Si compilo bajo x64 significa que el Release de la aplicación solo podría ejecutarse en ordenadores de 64 bits?
Si compilas para x64 significa que estás haciendo la app compatible unicamente para Windows de 64 Bits, ya estés generando la compilación en modo Debug o en modo Release (obvio)
Una vez leí que x86 era lo mismo que x32
x86 = 32 Bits.
x64 = 64 Bits.
x32 = NADA.
Es un término incorrecto que tiende a ser utilizado en el sentido de querer referirse a "32-bit", pero por simple desconocimiento del término adecuado.
El término x32 tendría sentido por ejemplo si estuvieramos hablando de Linux (x32
ABI).
mi ordenador es de 64 bits y al abrir el proyecto se muestra esto
Ahá, es por que has elegido el modo Release a 32 Bits.
Puedes modificar la arquitectura a 64 Bits o Neutral (
AnyCPU) en cualquier momento, desde ahí y también en la pestaña "Compile" de las propiedades de la solución de Visual Studio (En el explorador de soluciones ->
Click derecho en el nombre de la solución "WES II" -> "Properties").
Nota: Si compilas en modo Neutral (es decir,
AnyCPU), cómo estás bajo un Windows de 64 Bits entonces se te ejecutará la versión de 64 Bits (aunque, cabe mencionar que se puede especificar que haga lo opuesto).
En Java por alguna razón me acostumbré a escribir "código inicial" para los formularios en el constructor... pero como en VC++ al dar doble click sobre el formulario cargaba un método asociado al evento Load, creí que era lo correcto.
No, no es incorrecto, simplemente es innecesario ...mientras las circunstancias no requieran que añadas un Conctructor.
Ten en cuenta que Visual Studio es la IDE más completa, elaborada y optimizada para el desarrollador (indiferentemente de sus lenguajes soportados), la IDE siempre va a intentar automatizarte las tareas más comunes... cómo la que has comentado, pero eso no significa que manipular el código auto-generado por Visual Studio sea algo incorrecto, siempre que sepas lo que estás haciendo, claro está.
Sí lo intenté, pero el contenido de la ventana no cargaba. Luego noté que hacía falta usar InitializeComponent(), como usted lo menciona.
Claro, si te fijas verás que el método
InitializeComponent es un método que contiene código auto-generado que está en la Class
X.Designer.vb (donde "X" sería el nombre del Form), donde se inicializan todos los objetos/controles del Form y se le asignan los valores de las propiedades por defecto y las que hayas modificado en tiempo de diseño (en el constructor de la GUI), si no llamas a ese método ...entonces no hay Form xD.
Por si no lo sabias, es suficiente con que escribas
public sub new, le das a la tecla
Enter, y Visual Studio ya te genera este código:
Public Sub New()
' This call is required by the designer.
InitializeComponent()
' Add any initialization after the InitializeComponent() call.
End Sub
El mismo "truco" (si se le puede llamar así) también lo puedes aplicar al declarar implementaciones, por ejemplo:
Escribir
public class form2 : implements idisposable + pulsar tecla
Enter, generará este código:
Public Class form2 : Implements idisposable
#Region "IDisposable Support"
Private disposedValue As Boolean ' To detect redundant calls
' IDisposable
Protected Overridable Sub Dispose(disposing As Boolean)
If Not Me.disposedValue Then
If disposing Then
' TODO: dispose managed state (managed objects).
End If
' TODO: free unmanaged resources (unmanaged objects) and override Finalize() below.
' TODO: set large fields to null.
End If
Me.disposedValue = True
End Sub
' TODO: override Finalize() only if Dispose(ByVal disposing As Boolean) above has code to free unmanaged resources.
'Protected Overrides Sub Finalize()
' ' Do not change this code. Put cleanup code in Dispose(ByVal disposing As Boolean) above.
' Dispose(False)
' MyBase.Finalize()
'End Sub
' This code added by Visual Basic to correctly implement the disposable pattern.
Public Sub Dispose() Implements IDisposable.Dispose
' Do not change this code. Put cleanup code in Dispose(disposing As Boolean) above.
Dispose(True)
GC.SuppressFinalize(Me)
End Sub
#End Region
End Class
ese tip lo hace considerando de que quiero escribir "código inicial" que pueda cerrar la ventana en algunos casos y que quiero que la ventana no llegue a observarse nunca si tales casos ocrreun, ¿verdad?
Sí, por que de otro modo, si intentases cerrar el Form en el Constructor no podrías cerrarlo ya que al llamar al método
Form.Close se intentaría liberar (llamando internamente al método
Form.Dispose) un Form que todavía no ha sido inicializado, y eso lanzaría una excepción.
Y si lo intentases en el método que controla el evento
Form.Load bajo una app x64 y ocurriese la excepción que mencionaste pues... ya sabes lo que pasaría.
Así que ...sí, pienso que lo mejor sería ejecutar esas instrucciones en el método que controla el evento
Form.Shown.
De todas formas, si ahora ya estás controlando la excepción que mencionaste, es decir, si la tienes encerrada un bloque
Try/Catch, entonces si que puedes usar el evento
Form.Load para cerrar el form (sin que sea visible ni nada), o suplantar el método
Form.OnLoad o
Form.OnControlCreated, cómo te muestro en este ejemplo:
Public NotInheritable Class Form2 : Inherits Form
<DebuggerStepThrough>
Protected Overrides Sub OnLoad(e As EventArgs)
Me.MyMethod()
MyBase.OnLoad(e)
End Sub
<DebuggerStepThrough>
Private Sub MyMethod()
Try
Throw New Exception(message:="Excepción intencionada.")
Catch ' ex As Exception
MyBase.Close()
End Try
End Sub
End Class
Saludos!
Autor
En línea
