Daniel Garcia-Gil wrote:Saludos
lo probe con varios controles y en lo unico que funciona es en los LABEL
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...
¿
SEL Selector = NSSelectorFromString( @"Mensaje:"); // Ojo que hay que especificar ":" al final del nombre del mensajeSEL Selector = NSSelectorFromString(@"MyMethod:AndSecondValue:");
[self performSelector:Selector withObject:@"My String" withObject:[NSNumber numberWithInt:10]];- (void) forwardInvocation: (NSInvocation*)anInvocation
{
if ([anObject respondsToSelector: [anInvocation selector]])
return [anInvocation invokeWithTarget: anObject];
else
return [self doesNotRecognizeSelector: [anInvocation selector]];
}local oWnd := NSObject():New( UIWindowAllocInit() )
oWnd:setBackgroundColor = ...
// que se traduciría a:
[ hObj setBackgroundColor : ... ]; // oWnd:hObj en PRGAntonio 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
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
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
