SoloCodigo

Lo primero es que este es un foro de Visual C++, no de GCC, así que la pregunta debería haber sido hecha en el padre.

Lo segundo es que el compilador desconoce de dónde vienen xmlNodeGetContent y demás, por lo que, de momento, al menos te falta incluir algunos ficheros .h más. ¿Cuáles, pues ni idea?

No sé si el código funciona o no, pero intentar deshabilitar UAC en XP es como correr delante de un ladrón para pillarlo: XP no tiene UAC y por lo tanto esas claves del registro no existen...

bueno, suponiendo que se puede "esconder" un programa en ejecucion, osea que sea visible solo de la ventana de procesos, crear un timer en unos 30 segs, y revisar si tal proceso esta activo y si no iniciarlo, recuerdo hacer eso que era algo como

un bool que revisaba si existia el proceso
private bool existe()
{
Foreach (Process p in pr)
{
if (p.Name == nombreprocesoquedeseasmantenerabierto)
   return true;
}
return false;
}

entonces en el metodo del timer
if(existe == false)
   Process.Start("direccion del proceso necesario")

aunque no se si esto satisface todas tus necesidades

En ese caso, si el programa vigilante se cae, ya no puedes hacer nada. En el caso de un servicio (más o menos con tu código) y se cae por cualquier motivo, windows lo vuelve a levantar automáticamente.

Supongo que se podrá leer por WMI, pero no sé cómo.

La medida de la temperatura en un micro ha ido evolucionando a lo largo del tiempo. Primero llevaban las placas base un sensor justo debajo del zócalo, y luego AMD puso de moda que fuera el propio micro el que se leyera a sí mismo su propia temperatura.

En todos los casos supone acceder al hardware, y dependiendo del micro y de la edad del mismo se hace de una forma o de otra. En el caso de que sea la placa base la que mida la temperatura, tendríamos que acceder a los datos de la bios (ojo, a los datos, no a la bíos).

En el caso de un micro moderno, existen instrucciones en ensamblador para obtener dicho valor, y si no existen, se hace accediendo al "espacio de direcciones del micro", es decir, una dirección de memoria absoluta fuera de cualquier virtualización de memoria te daría el valor de la temperatura.

Bueno, en ambos casos, realmente el valor no, sino un número con el cual, aplicando una ecuación que es diferente para cada micro y manera de leerla, te daría el valor real de la temperatura.

Pero para todo eso es necesario acceder al anillo 0 y con instrucciones de modo privilegidado: en otras palabras, o te permite el WMI (que lo ignoro, y muchas veces lo que se lea ahí suele ser bastante impreciso) o te tienes que hacer un driver de dispostivo, que será diferente para cada combinación de procesador/placa base (Y es por eso por lo que cada fabricante de placas base te da un programa para mirar la temperatura y no suele haber uno que lo haga para cualquier micro/placa base, y si los hay, que los hay, en general si tienes la suerte de que hayan implementado el algoritmo y el driver de tu sistema, podrás ver la temperatura. En otro caso, ni siquiera puedes estar seguro de que el valor que te muestren sea cierto).

Pues tan sencillo como comparar los valores de la propiedad "Value". Son objetos y ellos mismos saben compararse:

if(dateTimePickerMax.Value<dateTimerPickerMin.Value)
{
//etc
}

No entiendo bien qué quieres hacer, pero Visual Studio 2010 permite trabajar perfectamente con código no manejado sin problemas. Trae MFC y Win32 y aplicaciones de consola como ha traído de siempre. Tienes una pestaña de Win32 y otra de MFC en el asistente para un nuevo proyecto.

También puedes trabajar con QT incluso de forma "cuasi" integrada a no ser que pagues una licencia de QT (y entonces sí que puedes integrarlo todo).

Mira estas entradas de mi blog: http://geeks.ms/blogs/rfog/archive/tags ... fault.aspx

El método tradicional es hacer un getter/setter o ponerla en la zona pública. De cabeza (puede tener errores):

class Clase
{
private:
int m_privada;
public:
int GetPrivada(){return m_privada;}
void SetPrivada(int valor){m_privada=valor;}
int VariablePublica;
};


Clase miClase;
miClase.SetPrivada(3);
cout<<miClase.GetPrivada();
miClase.VariablePublica=4;
cout<<miClase.VariablePublica;

Claro que puedes usar la DLL desde C++/CLI, pero tienes que tener en cuenta que son lenguajes diferentes y que necesitan una interoperabilidad, que debería venir explicada en el libro de Horton.

Los tipos nativos son intercambiables, pero las cadenas y las estructuras y punteros no. O bien usas interop por atributos (los corchetes puestos encima de las definiciones de los métodos) o bien por IJW, que consiste en simplemente usar los tipos y demás pero pinneándolos etc... No es sencillo.

Con la DLL te tendrían que haber dado un fichero LIB que deberías añadir al proyecto, a no ser que el CPP que te han dado use LoadLibrary() y use punteros a función, que luego serán usados desde otras clases como si fueran funciones normales.

Pues es a esas funciones a las que les tienes que aplicar el interop.

Lo más fácil es que te generes una DLL con una o varias clases en C++/CLI que envuelvan dichas funciones (ya sea mediante LoadLibrary o mediante el uso del .h y del lib), y entonces usar la nueva DLL en conjunto a la antigua ya como .NET puro y duro.

Que yo sepa no hay documentación en castellano sobre todo esto. Lo más cercano es mi blog, en el que trato alguna de estas cosas, pero no mucho: geeks.ms/blogs/rfog.

Estás mezclando churras con merinas.

Estás intentando heredar una clase de WIndowsForms como si fuera MFC.

WindowsForms usa un lenguaje similar al C++ que se llama C++/CLI.

Todos los errores vienen porque el compilador no ve la definición de la clase, y por tanto no sabe qué es clsTimeOutTimer.

¿Incluiste el fichero cabecera adecuado?

Una cosa: una aplicación WindowsForms NO es C++, es C++/CLI que es un lenguaje diferente.

http://blogs.msdn.com/b/vcblog/archive/ ... 58277.aspx

La solución a todos los problemas de la última actualización.

No tengo ni idea, pero prueba.

Cuando esté desinstalado, borra a mano las carpetas del SDK en Archivos de Programa.