Buenas Noches @migos:
tratando de ser breve, les diré que mi problema es que declare una variable publica en un modulo, el problema consiste en que al intentar dar el valor del valuebox no me funciona ya que me indica el error: TYPE MITCHMAD: wanted number, got integer[] instead, pueden hacer favor de ayudarme, estoy iniciando en gambas y no encuentro el error, anexo el fragmento de codigo donde me tira el error. gracias por su ayuda.

PUBLIC SUB vbxEjesX_KeyPress()

   IF (Key.Code = Key.Enter OR Key.Return) THEN
  var.MarcosX = vbxEjesX.Value
  vbxEjesY.SetFocus
  ENDIF

END

no pones como tienes declarado var.marcosX. Entiendo que lo tienes declarado como entero y que el error que te da es en la linea var.MarcosX = vbxEjesX.Value

¿Puede ser que el valor de vbxejex en ese momento no sea un entero?
Para saberlo pon a esa linea delante un try y luego en la linea siguiente pon print vbxejex.value y en la siguiente pones un punto de interrupción. En la consola deberías ver lo que en ese instante vale el valuebox y seguramente entenderás la razón por la que no puedes meter eso en una variable entera.



Un saludo.

Buenos días, te agradezco bastante la atención al responder pronto a mi pregunta...es cierto, se me paso comentar como declaro la variable:

la variable la declaro como:
Public MarcosX as Integer[]

Saludos y gracias por su apoyo.

Has declarado MarcosX como una matriz de Enteros, no como un entero.
decláralo como



y no tendrás más ese error.

Suerte

===================
No podemos regresar

GRACIAS!!!!

Muchas gracias, e probado como indico soplo y shordi, ahora si me funciona, asi que puedo dar por solucionado el tema.

no se si aqui sea lo correcto, pero una pregunta mas...

en mi proyecto tengo declarada una variable de esta manera:

Public Ejemplo[X,Y,Z] As double
donde X, Y, Z son declarados con anterioridad como integer (Public X as integer)
sería posible realizarlo? es la sintaxis correcta?

como siempre agradezco su atención.

Sin ver el código completo no te puedo decir si funcionará o no, ahora bien, de todas tus declaraciones se ve que abusas absolutamente de las variables PUBLIC. Prácticamente NUNCA deberías utilizar éste tipo de variables (nótese el "prácticamente", que indica que a veces, en contadas ocasiones, por vaguería de no hacer las cosas como es debido o por ignorancia de hacerlas mejor todo el mundo las ha utilizado). Una variable PUBLIC es una fuente segura de problemas en el futuro de tu aplicacion.

Suerte.

===================
No podemos regresar

Hola.

A Shordi.

Pero la variable publica es común usarla ya que es global al formulario, modulo.
Es reconocida por todos los procedimientos o funciones que se encuentre esta.
Con locales, aumentarías el numero de variables.Claro que liberaría la memoria
al salir del procedimiento o función.

De la otra forma siempre tendría un valor ocupando la publica.
Entonces de las constante ni hablar,no.

Saludos.

===================
Gambas Básico
"No es un bug, es una característica no documentada"

Citar:

Pero la variable publica es común usarla ya que es global al formulario, modulo.

No exactamente. La variable publica es común a la aplicación entera (técnicamente a toda clase que tenga una referencia a la clase o módulo donde se declara, que otro tema es que los símbolos de los formularios sean públicos o no). Si deseas una variable visible al módulo o clase utiliza una PRIVATE.

Citar:

Es reconocida por todos los procedimientos o funciones que se encuentre esta.

El que sea reconocida por todos los procedimientos o funciones es, precisamente, el problema.
Sin entrar en la POO, el tema del encapsulamiento ya era propio de la programación estructurada. Una variable pública puede ser modificada desde cualquier sitio, y por tanto no puede ser controlada con precisión. Un  ejemplo: Imagínate que almacenas la clave del individuo actual en tu aplicación de clientes en una variable pública. Perfecto, así sé en cualquier sitio "de quien estamos hablando" y no tengo que preocuparme de nada más. Sin embargo eso sólo funciona si en todos los "vaivenes" del flujo de la aplicación (funciones que llaman a funciones que a su vez llaman a otras funciones y luego vuelta atrás) ninguna toca el contenido de esa variable... si es que no hay que tocarlo, claro.
Cuando haces la versión Alfa de tu aplicación todo está muy claro en tu cabeza y todo funciona guay. Cuando 6 meses -o dos años- después tienes que añadir una funcionalidad o modificar otra en la aplicación... ya no está tan claro. ¿BuscaNuevoTio(dni as string) as boolean, cambiaba la variable global? ¿y CancelaCambios(res as result) as result) ¿Pregunta si cambioDni(cDni as string) llegaba a cambiarla si se pulsaba cancel?, etc. etc.
Y eso con variables string o integer, que cuando hablamos de variables como result, que son "tocadas" por las clases internas de gambas, muchas veces sin pretenderlo nosotros, ya ni te cuento. ¿Un .update fallido me cambia el contenido de mi result público?, un movenext para ver si era el último o no me guarda los cambios no grabados al hacer moveprevious?...
Creo que me explico. Variables públicas las mínimas.

Y que conste que no soy ningún pureta del asunto, que en mis aplicaciones hay variables públicas. Que muchas veces las creo "temporalmente hasta que haga una clase" y así se quedan per secula seculorum... pero es que nadie es perfecto, oiga. Aunque conviene distinguir las buenas y malas prácticas...

Citar:

Con locales, aumentarías el numero de variables.Claro que liberaría la memoria
al salir del procedimiento o función.

Eso es cierto... casi siempre. Con la memoria que tienen las máquinas hoy día no es muy relevante el número de variables (salvo que te lances a crearlas en bucles y cosas así), pero no siempre se destruyen al finalizar la función que las crea. No olvides las que antes llamábamos (no sé si ahora se siguen llamando así) variables locales separadas, que si no controlas también pueden dar problemas...

El trabajo no me dejaba tiempo para contestar, pero gracias a ambos por la ayuda y comentarios...me han aclarado varias dudas.

Saludos.