Para empezar tu código es horrible, no lo tomes a mal, o bueno mejor si. Aparte no tiene sentido que plantes mil líneas de código porque sí... tienes que hacer tú la labor de investigación, aislar el problema e intentar solucionarlo. Si aún así te atascas entonces es cuando vienes aquí y plasmas la zona problemática comentando hasta dónde has llegado.

Llegar a un foro y decir... no me funciona mi programa... ahí os lo dejo... es lo que he dicho otras veces, ese tipo de trabajos cuestan dinero.

Si quieres que el código sea un poco más legible edita tu mensaje y la etiqueta que engloba el código modifícala para que quede tal que [ code = c ] pero sin espacios.

Después estaría genial que tabulases el texto para poder seguir un poco la traza de forma visual sin dejarse la vista.

Tener funciones cuyo nombre no dice nada como puntoa, puntob, puntoc es de las peores decisiones que puedes tomar a la hora de programar... ese nombre no aporta nada y tener que recordar después de unas semanas lo que hacía esa función puede significar recorrer un tortuoso camino.

No uses fflush( stdin ) no es portable y puede dar muuuchos problemas, hay otras formas más elegantes y usables de limpiar el buffer de entrada... por ejemplo ( no digo que tengas que usar esta, ni que sea la mejor, ni la única )

fseek( stdin, 0, SEEK_END );

Al fin y al cabo el buffer de entrada tiene la misma estructura en memoria que un archivo.

Más cosas, el primer elemento de un array es siempre el que tiene índice 0, por lo que las líneas

for(i=1;i<CE;i++)printf("\t Legajo: %d, Categoria: %s, Sueldo anual del docente %5.2f\n",vle[i],vnom[i],vsa[i]);
 
for(i=1;i<CM;i++) printf("\t Numero del mes : %8d Cantidad de sueldo pagado %15.2f\n",i,vcmeses[i]);
 
for(f=1;f<CM;f++)
{
  max = -999;
  for(c=1;c<CE;c++)
  {
    if(mme[f][c] > max)
    // ... 

Están necesariamente mal ( y puede que haya más ).

Ah si, y aprende a usar el depurador... un programador que no sabe depurar un programa es como un arquitecto que no sabe diseñar planos.

Yo creo que sí es posible sacar una metodología común y abstraer al usuario de la arquitectura que hay por debajo.

Tu piensa que hacer un sistema multiplataforma no siempre va a ser encontrar dos funciones que hacen lo mismo, con los mismos parámetros y preparar un wrapper para encapsularlo... la multiplataforma es generalmente más complicada y exige un estudio mayor.

Es demasiado complicado poder sacar en multiplataforma las resoluciones disponibles para el monitor que se esté usando??

Se supone que si haces una aplicación la idea es que se vea bien en cualquier equipo, si no eres capaz de sacar las resoluciones sabrás que tu aplicación se ve bien en tu máquina, pero en el resto...

Si pensabas hacerla compatible con c la cagaste al usar la clase string en la interfaz ...

También puedes revertirlo y usar un array de char en vez de la clase string

También he visto que la librería está pensada para ser utilizada con c++... no te sale más a cuenta en este caso agrupar las funciones y presentarlas encapsuladas en clases ??

creo que el manejo entonces sería muchísimo más intuitivo a la par de sencillo.

No se, se me ocurre quizas un código tal que:

ventana.Clean( );
ventana.DrawRect( rect1 );
ventana.DrawPoint( point1 );
 
random.NewSeed( );
int number = random.GetRandom( 0, 20 );
 

En vez de estar llamando una y otra vez a funciones inconexas.

En tal caso, si no quieres beber de la fuente de la locura, hazte esquemas en papel donde quede bien claro que arrays tienen que ir de la mano y qué almacena cada uno.

Mantener demasiada información en la cabeza no suele ser una buena idea si quieres que tu software funcione.

Esos no estaban en tu mensaje

En ese caso retiro mi consejo 3.

Por cierto, a mi también me ha gustado eso de que intentas que sea multiplataforma.

Un ejemplo sencillo de la utilidad de las estructuras.

Imagínate que tienes que gestionar una clase de 30 alumnos y para cada alumno necesitas guardar su nombre, sus apellidos, su edad, y la nota media de cada trimestre.

con estructuras:

struct alumno
{
    char nombre[MAX];
    char apellidos[MAX];
    int edad;
    float nota_media[3];
};
 
struct alumno alumnos[30];
 
void imprimir( struct alumno alumnos[30] )
{
  int i;
  for ( i=0; i<30; ++i )
  {
    printf( "%s\n", alumnos[ i ].nombre );
    printf( "%s\n", alumnos[ i ].apellidos );
    printf( "%d\n", alumnos[ i ].edad );
 
    // y esto podría ir en otro bucle
    printf( "%f\n", alumnos[ i ].nota_media[ 0 ] );
    printf( "%f\n", alumnos[ i ].nota_media[ 1 ] );
    printf( "%f\n", alumnos[ i ].nota_media[ 2 ] );
  }
}

sin estructuras

char nombres[30][MAX];
char apellidos[30][MAX];
int edades[30];
float notas_medias[30][3];
 
// ...
 
void imprimir( char nombres[30][MAX], char apellidos[30][MAX], int edades[30], float notas_medias[30][3] )
{
  int i;
  for ( i=0; i<30; ++i )
  {
    printf( "%s\n", nombres[ i ] );
    printf( "%s\n", apellidos[ i ] );
    printf( "%d\n", edades[ i ] );
 
    // y esto podría ir en otro bucle
    printf( "%f\n", nota_medias_medias[ i ][ 0 ] );
    printf( "%f\n", nota_medias_medias[ i ][ 1 ] );
    printf( "%f\n", nota_medias_medias[ i ][ 2 ] );
  }
}

Queda claro que con estructuras todo queda más recogido y "estructurado"... sin estructuras cada array va a su bola y es muy fácil meter la pata.

Pues a ver, para manejar los datos lo mejor sería utilizar estructuras de datos.

El lote 1 podría ser algo así

struct lote1
{
    char[MAX] legajo;
    int mes;
    char[MAX] categoria; // si fuese un indice podrias usar un int o un puntero
    int horas_trabajadas;
};

Y el lote 2...

struct lote2
{
  char[MAX] titular;
  char[MAX] asociado;
  char[MAX] adjunto;
};

... a no ser que los datos del lote 2 sean referencias, en cuyo caso deberías sustituir los arrays por punteros.

Es un buen comienzo.

No soy un fan de las aplicaciones de consola, por lo que no te sabría valorar la utilidad de tu api, pero todo lo que sea abstraer al programador de la programación a bajo nivel ( si es con cierto sentido ) siempre es bien recibido.

Consejo: La api, o la creas con funciones en español o la creas con funciones en inglés... mezclar ambos idiomas no suele ser intuitivo cuando el sistema crece.

Consejo 2: Creo que si la api crece sería más manejable y eficiente implementar las funciones para que acepten estructuras para el caso, por ejemplo, de puntos y rectángulos. Soy partidario de pasar una estructura como referencia a tener que meter 4 parámetros en una función.

Consejo 3: Desde mi punto de vista falta al menos una función que te devuelva los límites de la pantalla.

Un saludo.