FiveTech Software tech support forums

Daniel Garcia-Gil wrote:Saludos
lo probe con varios controles y en lo unico que funciona es en los LABEL

Daniel no entiendo muy bien lo que me dices aqui . Yo en mis pruebas he implementado unos cuantos controles mas y funcionan correctamente desde recursos ademas de los labels tengo los tableview , los picker, etc...
¿

mastintin wrote:

Daniel Garcia-Gil wrote:Saludos
lo probe con varios controles y en lo unico que funciona es en los LABEL

Daniel no entiendo muy bien lo que me dices aqui . Yo en mis pruebas he implementado unos cuantos controles mas y funcionan correctamente desde recursos ademas de los labels tengo los tableview , los picker, etc...
¿

Yo lo probe con todos los controles que aparecen dentro del nib y el unico que funciona es el UILabel, probe con otros controles con el mismo resultado... solo me arroja un handle valido los UILabel
(puede que me embote)

Daniel he subido un hola.nib y un tutornibs.prg que a mi me funcionan sin problemas ... tableview desde recursos... mira a ver si a ti te funcionan bien .
la captura es esta :

He hecho una primera aproximacion de como poder personalizar las celdas de untableview con una clase Tableviewcell que nos puede dar mucha versatilidad .
Estilo pijama :

Ando analizando y considerando el establecer un "puente" desde PRG a Objective-C que tal vez pueda ser más cómodo que construir todo desde Objective-C.

La idea es rutar los mensajes enviados a un objeto desde PRG a sus correspondientes mensajes en Objective-C. Veo ventajas e inconvenientes, por eso voy a comentar lo que he visto y asi lo analizamos entre todos

Para enviar un mensaje a un objeto en Objective-C se usa un "selector". La clave está en que podemos construir un selector a partir de una cadena:

Code: Select all  Expand view

SEL Selector = NSSelectorFromString( @"Mensaje:"); // Ojo que hay que especificar ":" al final del nombre del mensaje
 

Pasando varios parámetros al mensaje:

Code: Select all  Expand view

SEL Selector = NSSelectorFromString(@"MyMethod:AndSecondValue:");
[self performSelector:Selector withObject:@"My String" withObject:[NSNumber numberWithInt:10]];
 

Asi, podriamos rutar el mensaje enviado a un objeto (usando ON ERROR) en nivel PRG y generar un selector en Objective-C. Además podemos comprobar si el objeto en Objective-C soporta ó no dicho mensaje:

Code: Select all  Expand view

- (void) forwardInvocation: (NSInvocation*)anInvocation
{
  if ([anObject respondsToSelector: [anInvocation selector]])
    return [anInvocation invokeWithTarget: anObject];
  else
    return [self doesNotRecognizeSelector: [anInvocation selector]];
}
 

En este código entra en juego un nuevo elemento, la clase NSInvocation, que permite controlar parámetros, valor de retorno, objeto al que se envia el mensaje.

Las pegas que le veo es que desde PRG solo disponemos de un número muy límitado de "tipos". Asi que necesitariamos usar funciones que creasen los tipos extra que hiciesen falta.

La idea es crear una Clase NSObject que guardaría el handle del objeto Objective-C y que podria usarse algo así:

Code: Select all  Expand view

local oWnd := NSObject():New( UIWindowAllocInit() )

oWnd:setBackgroundColor = ...

// que se traduciría a:

[ hObj setBackgroundColor : ... ]; // oWnd:hObj en PRG
 

Bueno, aqui tenemos este camino. Tal vez podemos implementarlo como algo adicional a lo que ya tenemos...

Antonio muy interesante .
El poder construir un selector desde una cadena nos da la posibilidad de poder decidir desde prg el selector a utilizar por un mismo objeto dependiendo de unas determinadas condiciones .
Una pregunta que debemos hacernos cuando trabajamos con dispositivos "pequeños" ( y no pensemos en iphone4 , sino en iphone 3g ) es cuanto penaliza este proceso en la velocidad del programa . No existe nada peor que un "usuario" desesperado por lo que tarda el programa .Digo esto porque estos dias al implementar nuevas funcionalidades en el tableview veo que la velocidad se degrada mucho cuanto mas idas y venidas a prg hagamos .
Es una cosa que tendremos que valorar , sino penaliza mucho o incluso nos da mas velocidad pues evita traspasos , puede ser muy buena idea a pesar de los contras , si degrada velocidad es el mayor "contra" para no usarlo .
Saludos

Implementado y subido un primer prototipo de la Clase NSObject y samples/object.prg

Aún no probado...

Editado: Manuel hagamos algunas pruebas y a ver que tal va

Daniel,

He modificado HB_GARBAGE_FUNC( OBJECT_release ) para solucionar los warnings que teniamos.

Habria que probar si el nuevo código funciona bien

Menuda barrera:

Los mensajes que enviamos desde PRG se traducen a MAYUSCULAS y no es el formato que espera Objective-C.

me parece que hemos topado por ese camino con un obstaculo insalvable...

Bueno, hemos aprendido cosas nuevas de todas formas

Antonio Linares wrote:Menuda barrera:

Los mensajes que enviamos desde PRG se traducen a MAYUSCULAS y no es el formato que espera Objective-C.

me parece que hemos topado por ese camino con un obstaculo insalvable...

Bueno, hemos aprendido cosas nuevas de todas formas

Menuda faena . Como mal estamos como estabamos y mas sabios

Si es un "obstaculo insalvable" es una mala noticia luego de tanto trabajo de parte de ustedes y tanta expectacion de parte nuestra.
Por otro lado creo que el Window Phone OS debiera tener un alto grado de compatibilidad con el Windows Mobile.
Quizas FiveTech pueda realizar algunos experimentos con el Windows Phone aprovechando la experiencia y el exito de FWPPC.


Saludos


George

George wrote:Si es un "obstaculo insalvable" es una mala noticia luego de tanto trabajo de parte de ustedes y tanta expectacion de parte nuestra.
Por otro lado creo que el Window Phone OS debiera tener un alto grado de compatibilidad con el Windows Mobile.
Quizas FiveTech pueda realizar algunos experimentos con el Windows Phone aprovechando la experiencia y el exito de FWPPC.


Saludos


George

George . Esto no significa que no podamos hacer nada , simplemente cierra una manera de rutar los eventos de prg a objective-c
La forma que usabamos hasta ahora sigue siendo valida , quizas necesite mas trabajo por nuestra parte , pero tambien nos acerca mas al codigo "nativo"( objective-c) del iphone.
Un saludo.

George

Antonio se referia al "obstaculo insalvable" a no poder usar tecnica que se intento implemntar para el manejo de mensajes... el desarrollo continua con la tecnicas actulaes.

Oh Gracias por la aclaracion. Es una buena noticia.
Entendi lo de 'obstaculo insalvable' como que no se podia seguir con las pruebas que ustedes venian haciendo con el iPhone.

Adelante y animo!

Saludos

George

Probando FivePhone en el iPad y funcionando correctamente!