Cada dia que passa, o "quebra-cabeças" vai se complicando ainda mais.
Vamos ver se entende assim...
No xBase você prepara toda a tela...
@ 1, 0 SAY "código" GET código
@ 2, 0 SAY "Nome"GET nome
@ 3, 0 SAY "outro" GET outro
e depois faz o ambiente funcionar
READ
Na programação Windows isso envolve a tela completa, com tudo.
textbox
label
botões
menus
sei lá mais o que...
E depois ativa tudo
activate, show, etc.
Essa é a grande diferença.
Não dá pra ir colocando textos na tela depois, ou algo assim.
Tudo tem que estar definido antes, nem que seja apenas um espaço aonde vai ser colocado o texto.
O Windows passa a tomar conta, e apenas repassa os eventos para o programa.
O usuário clica num botão, o Windows repassa ao programa que o botão foi clicado e o programa faz o que precisa.
Em console: o programa gerencia tudo sozinho
Em Windows: o Windows gerencia tudo, apenas repassa eventos para o programa, e o programa trata aquele evento, uma coisa por vez, durante a execução.
Então... uma vez o aplicativo em GUI, ele deve obedecer a LIB gráfica, que por sua vez deve obedecer o Windows.
Você pode fazer o que quiser... mas deve obedecer as necessidades das LIBs gráficas, que obedecem as necessidades do Windows.
Outra coisa também: não parece, mas cada desenho numa tela GUI é uma janela diferente, é como se fosse um programa diferente, um zumbi recebendo ordens.
Numa tela console - considere de certa forma a GTWVG também:
moveu a janela de lugar, o texto da janela vai ser reescrito, o aplicativo apenas precisa reescrever o texto da tela e fim.
Numa tela GUI:
A janela principal vai ser movida, o programa avisa ao windows para mover também todas as janelas internas com texto, desenhos, etc. (botões inclusive).
A cada objeto movido, tá lá o windows e o aplicativo (lib gráfica) trocando mensagens pra dizer o que fazer.
Vamos ver de outra forma... o meu monitor 4k....
A tela console trabalha com 40 x 100, o que equivale a 4.000 caracteres/elementos
Em modo gráfico, 3840 x 2160 = 8.294.400 pixels/elementos.
E cada elemento pode ser uma cor diferente.
Gerenciar 4.000 elementos é mais rápido do que gerenciar 8 milhões de elementos.
A forma intermediária é dividir em janelas menores, objetos menores, que são gerenciados pelo Windows, e não pelo programa.
No final todo mundo sempre reclamou do desperdÃcio de computador que acontecia no Windows.... e agora todo mundo quer desperdiçar, dizem que é o normal.... rs
Parece piada, mas é sério, trocentos anos depois, o que era considerado errado virou o que é certo.
E vai piorar....
Telas de celular já tem 4k, então é mais que normal que telas de computador sejam muito mais que 4k, já tem monitor DELL de 8k.
Aqui o Windows reserva 10 GIGAS de memória só pra vÃdeo. 10 milhões de bytes, além dos 2 milhões de bytes que a placa tem.
8.000 bytes pra texto, 12 milhões de bytes pra vÃdeo, além dos bytes usados durante processamento....
Tela gráfica é coisa séria... o tempo dos 640KB de memória do Clipper se foram...
E se não tiver um bom gerenciamento de tudo isso gráfico.... ferrou....
Acho que ninguém parou pra pensar nesse ponto.... do que é gerenciado ao usar GUI...
Mas não tem volta...
Resumindo:
O Windows faz um gerenciamento doido pra controlar vÃdeo....
A LIB gráfica é obrigada a obedecer o Windows, pra esse controle funcionar bem...
O programador tem que obedecer a LIB gráfica...
Quer programar em GUI: obedeça a LIB que escolher.