he conseguido un iphone

[mastintin]

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...
¿

[Daniel Garcia-Gil]

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)

[mastintin]

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 :

[mastintin]

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 :

[Antonio Linares]

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

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

Pasando varios parámetros al mensaje:

Code: Select all

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

- (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

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...

[mastintin]

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

[Antonio Linares]

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

[Antonio Linares]

Daniel,

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

Habria que probar si el nuevo código funciona bien

[Antonio Linares]

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

[mastintin]

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

[George]

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

[mastintin]

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.

[Daniel Garcia-Gil]

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.

[George]

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

[Antonio Linares]

Probando FivePhone en el iPad y funcionando correctamente!