Aiuto sulle Api (nozioni di base)

[Gino+89+]

Allora, sto studiando da diverso tempo le API, e mi sono sorti alcuni dubbi che non rieso a colmare (sia di codice che di GUI in generale)..

1) Allora, ho capito come creare un dialogo e i suoi rispettivi controlli...però mi è sfuggita una cosa, come posso includere controlli (tipo edit, bottoni etc) nella finestra principale senza creare dialoghi aggiuntivi??...

2) Come posso dire alla finestra principale di "prendere del testo" (mamma mia), tipo il notPad di Windozz?? (ho visto diversi tutorial ma non ho capito bene lo stesso)

3) non ho ben capito il significato di finestra figlia (o meglio cosa la differenzia da una qualsiasi altra)...nel senso...potrebbe essere un dialogo non modale per esempio??...

4)Sento spesso parlare di DLL studiando le API...mi potreste brevemente spiegare cosa sono e a cosa servono? (senza andare troppo nel particolare, al massimo come vengono incluse etc)...

5inta ed ultima) Sto studiando le API per conto mio (visto che a scuola non le trattiamo, non trattiamo proprio la GUI, faremo un pò di VB il prossimo anno ma non mi piace)...e mi è sorto un dilemma: mi conviene veramente continuare, o sarebbe meglio magari passare ad altre librerie come le gtk??...su vista (visto l'imminente cambiamento) saranno presenti in modo uguale?? (cioè: le gtk saranno presenti su vista? e allo stesso modo le API subiranno cambiamenti?)...quale potrebbe essere il guadagno di un passaggio così? (da windows.h a gtk.h, se veramente un guadagno ci può essere)...

Ho posatato su questo forum perchè vedo che c'è gente che sene intende di queste cose (mi rendo conto che non sono poche ma sul web non ho trovato adeguata risposta a queste doamande)...ringrazio anticipatamente chiunque possa schiarirmi le idee...

[71104]

Originariamente inviato da Gino+89+

1) Allora, ho capito come creare un dialogo e i suoi rispettivi controlli...però mi è sfuggita una cosa, come posso includere controlli (tipo edit, bottoni etc) nella finestra principale senza creare dialoghi aggiuntivi??...

ottima domanda, poiché la risposta è che in maniera veloce non si può; hai 3 modi:
1) li crei manualmente di sana CreateWindow
2) li metti in una dialog e crei manualmente un'istanza modeless della dialog (CreateDialog) nella finestra principale
3) usi un tool RAD, come Visual Basic, Delphi, C++ Builder, o come le Windows Forms

2) Come posso dire alla finestra principale di "prendere del testo" (mamma mia), tipo il notPad di Windozz?? (ho visto diversi tutorial ma non ho capito bene lo stesso)

il notepad altro non è che un programma che crea nella sua main window un grosso controllo EDIT multiline. conosci gli edit, no?

3) non ho ben capito il significato di finestra figlia (o meglio cosa la differenzia da una qualsiasi altra)...nel senso...potrebbe essere un dialogo non modale per esempio??...

le finestre (non dialog, finestre di qualsiasi tipo) sono organizzate in due diversi alberi gerarchici: l'albero delle finestre legate al padre tramite il loro Parent e quello delle finestre legate al padre tramite il loro Owner. e parlo di alberi nel senso di normalissimi alberi come lo si intende nelle varie teorie di algoritmi (grafi connessi aciclici).

la differenza tra i due alberi è sottile, tant'è vero che spesso le finestre hanno per Parent e per Owner la stessa finestra. il Parent di una finestra è quella che la contiene graficamente (se la finestra figlia va fuori dalla client area del suo Parent, viene tagliata; se il Parent è invisibile, la finestra figlia è invisibile indipendentemente dalla sua visibilità).

l'Owner di una finestra invece è il suo Parent iniziale, che ha la proprietà di essere quella che ha la responsabilità di eliminarla. una finestra viene eliminata o su richiesta (DefWindowProc riceve WM_DESTROY) o su richiesta rivolta all'Owner; ma non al Parent.

spero di essermi ricordato tutto giusto e di non aver detto inesattezze...

4)Sento spesso parlare di DLL studiando le API...mi potreste brevemente spiegare cosa sono e a cosa servono? (senza andare troppo nel particolare, al massimo come vengono incluse etc)...

hai presente un exe? una dll è la stessa cosa: contiene codice, dati, e altra roba; con una minima differenza: l'exe è progettato affinché il suo codice abbia un inizio e una fine di esecuzione; la dll invece non si esegue direttamente, è solo un file che contiene pezzi di codice (funzioni) che altri exe possono "prelevare" ed eseguire.

i vantaggi di mettere codice in una dll:
1) se hai sul pc 100 eseguibili che fanno la stessa cosa, e quella cosa la fa una funzione che sta in una sola dll, i 100 eseguibili caricano tutti la stessa dll ed eseguono tutti la stessa porzione di memoria fisica risparmiando spazio su disco e in RAM
2) se quella cosa conteneva un bug, è sufficiente patchare solo la dll anziché ciascuno dei 100 eseguibili

5inta ed ultima) Sto studiando le API per conto mio (visto che a scuola non le trattiamo, non trattiamo proprio la GUI, faremo un pò di VB il prossimo anno ma non mi piace)...

un classico: probabilmente li ritengono argomenti troppo complessi; probabilmente il loro QI non arriva a quello di un ragazzo di 12 anni (visto che io ho iniziato a spulciarmi le API Win32 nell'implementazione della VCL di Delphi a 12-13 anni).

e mi è sorto un dilemma: mi conviene veramente continuare, o sarebbe meglio magari passare ad altre librerie come le gtk??...

sinceramente non so proprio rispondere... sono due diversi percorsi didattici, ciascuno con vantaggi e svantaggi.

su vista (visto l'imminente cambiamento) saranno presenti in modo uguale??

identiche. sarebbe un suicidio commerciale per Microsoft eliminarle
anzi, oltre alle funzioni già presenti in XP conterranno addirittura qualche funzione in più

(cioè: le gtk saranno presenti su vista?

be', ovviamente saranno compatibili

e allo stesso modo le API subiranno cambiamenti?)...

a volte capita che una funzione API Win32 abbia delle leggere differenze da una versione all'altra di Windows, ma:
1) succedeva prevalentemente da Windows 9x a Windows NT; ormai è storia, l'ultimo dei Windows 9x è andato
2) si tratta di differenze minime che non costituiscano comunque un "suicidio commerciale"
ricorda che qualsiasi differenza di protocollo è una nuova incompatibilità, una nuova dicitura "non supporta Vista" su buona parte dei programmi per Windows

quale potrebbe essere il guadagno di un passaggio così? (da windows.h a gtk.h, se veramente un guadagno ci può essere)...

il guadagno è enorme: la portabilità! (l'interfaccia GTK non cambia da Linux a Windows, ma chiaramente le API Win32 ci sono solo su Windows)
e ci aggiungiamo forse anche una maggiore semplicità rispetto alle API nude e crude; ma non sono sicuro perché non conosco.

[Gino+89+]

Prima di tutto grazie per le risposte

Originariamente inviato da 71104

ottima domanda, poiché la risposta è che in maniera veloce non si può; hai 3 modi:
1) li crei manualmente di sana CreateWindow
2) li metti in una dialog e crei manualmente un'istanza modeless della dialog (CreateDialog) nella finestra principale

Il terzo modo non mi piace e l'ho scartato...per i primi due mi potresti fare un esempio pratico (magari con solo il pezzo di codice interessato) così prendo il più semplice? (e magari vedo il punto esatto visto che negli esempi che trovo sul web (programmi interi) non lo afferro)

il notepad altro non è che un programma che crea nella sua main window un grosso controllo EDIT multiline. conosci gli edit, no?

Si li conosco, ma so solo implementarli in dialoghi separati, e quì si collega alla prima domanda visto che non so implementarlo a tutto schermo nella finestra principale..

le finestre (non dialog, finestre di qualsiasi tipo) sono organizzate in due diversi alberi gerarchici: l'albero delle finestre legate al padre tramite il loro Parent e quello delle finestre legate al padre tramite il loro Owner. e parlo di alberi nel senso di normalissimi alberi come lo si intende nelle varie teorie di algoritmi (grafi connessi aciclici).

la differenza tra i due alberi è sottile, tant'è vero che spesso le finestre hanno per Parent e per Owner la stessa finestra. il Parent di una finestra è quella che la contiene graficamente (se la finestra figlia va fuori dalla client area del suo Parent, viene tagliata; se il Parent è invisibile, la finestra figlia è invisibile indipendentemente dalla sua visibilità).

l'Owner di una finestra invece è il suo Parent iniziale, che ha la proprietà di essere quella che ha la responsabilità di eliminarla. una finestra viene eliminata o su richiesta (DefWindowProc riceve WM_DESTROY) o su richiesta rivolta all'Owner; ma non al Parent.

Quindi un dialogo modale potrebbre essere tipo una finestra figlia visto che se chiudo quella principale chiudo pure lui...no?

hai presente un exe? una dll è la stessa cosa: contiene codice, dati, e altra roba; con una minima differenza: l'exe è progettato affinché il suo codice abbia un inizio e una fine di esecuzione; la dll invece non si esegue direttamente, è solo un file che contiene pezzi di codice (funzioni) che altri exe possono "prelevare" ed eseguire.

i vantaggi di mettere codice in una dll:
1) se hai sul pc 100 eseguibili che fanno la stessa cosa, e quella cosa la fa una funzione che sta in una sola dll, i 100 eseguibili caricano tutti la stessa dll ed eseguono tutti la stessa porzione di memoria fisica risparmiando spazio su disco e in RAM
2) se quella cosa conteneva un bug, è sufficiente patchare solo la dll anziché ciascuno dei 100 eseguibili

Si ho capito...tipo una libreria in poche parole no?...

un classico: probabilmente li ritengono argomenti troppo complessi; probabilmente il loro QI non arriva a quello di un ragazzo di 12 anni (visto che io ho iniziato a spulciarmi le API Win32 nell'implementazione della VCL di Delphi a 12-13 anni).

Magari all'università le tratteranno penso...o sbaglio...

identiche. sarebbe un suicidio commerciale per Microsoft eliminarle
anzi, oltre alle funzioni già presenti in XP conterranno addirittura qualche funzione in più

Ok..

a volte capita che una funzione API Win32 abbia delle leggere differenze da una versione all'altra di Windows, ma:
1) succedeva prevalentemente da Windows 9x a Windows NT; ormai è storia, l'ultimo dei Windows 9x è andato
2) si tratta di differenze minime che non costituiscano comunque un "suicidio commerciale"
ricorda che qualsiasi differenza di protocollo è una nuova incompatibilità, una nuova dicitura "non supporta Vista" su buona parte dei programmi per Windows

il guadagno è enorme: la portabilità! (l'interfaccia GTK non cambia da Linux a Windows, ma chiaramente le API Win32 ci sono solo su Windows)
e ci aggiungiamo forse anche una maggiore semplicità rispetto alle API nude e crude; ma non sono sicuro perché non conosco.

Ok deciso..prima studio bene le API, così poi automaticamente le gtk le imparo molto più facilmente...

Edit: hai iniziato a 12-13 anni????...ma come hai fatto??...cos'è hai iniziato a programmare CUI a 7 anni??

[andbin]

Originariamente inviato da Gino+89+

Il terzo modo non mi piace e l'ho scartato...per i primi due mi potresti fare un esempio pratico (magari con solo il pezzo di codice interessato) così prendo il più semplice? (e magari vedo il punto esatto visto che negli esempi che trovo sul web (programmi interi) non lo afferro)

La soluzione migliore, in genere, è quella di usare le dialog-box. Basta avere un editor delle risorse per poter "disegnare" la dialog e poi basta usare le funzioni DialogBoxXXX (modali) oppure CreateDialogXXX (non modali) più una tua funzione che faccia da "dialog procedure" e il grosso è fatto.

La soluzione di usare la funzione CreateWindow è sicuramente possibile ma .... molto noiosa e lunga. In <questo> thread avevo postato un esempio completo per creare una finestra vuota (senza controlli). Guarda solo quanto codice serve per aprire una finestra vuota!

Originariamente inviato da Gino+89+

Quindi un dialogo modale potrebbre essere tipo una finestra figlia visto che se chiudo quella principale chiudo pure lui...no?

Per una dialog-box, il termine "modale" vuol solo dire che non potrai interagire con la finestra "owner" fino a quando non chiudi la dialog.

Originariamente inviato da Gino+89+

Si ho capito...tipo una libreria in poche parole no?...

Se intendi le librerie .lib, no. Una libreria .lib è detta anche libreria "statica". Essa viene fisicamente inglobata all'interno di ogni .exe che ne fa uso. Quindi, concettualmente, è l'opposto di una libreria dinamica .dll.

[jappilas]

Originariamente inviato da Gino+89+

Si ho capito...tipo una libreria in poche parole no?...

ehm, due piccoli incisi:
Una DLL (Dynamic Linked Library) E' una libreria sotto Windows, equivalente agli .o ed .so sotto Linux
-edit- forse tu ti rifersci ai file .lib ... cfr quello che ha scritto andbin

Apparentemente adesso si sta parlando di Win32 e quando dici API tu ti riferisci a queste...
Ma è da notare come API stia genericamente per Application Programming Interface: una API è una qualunque interfaccia di programmazione, intesa come specifica documentata delle funzioni o delle classi (con relativi metodi pubblici) che il programmatore può "vedere" e usare dal codice che sta scrivendo e che sono contenute in un altro pezzo di codice

si dice che una libreria _esporta_ una interfaccia (ma spesso anche un programma eseguibile, quando permette la creazione di plugins, ma per le librerie vale SEMPRE)

Ok deciso..prima studio bene le API, così poi automaticamente le gtk le imparo molto più facilmente...

rischi un po' di duplicare lo sforzo, ma devi decidere tu...

[71104]

Originariamente inviato da andbin

Guarda solo quanto codice serve per aprire una finestra vuota!

be', ma poi per inserire bottoni e altri controlli nativi è più semplice perché non devi definire nessuna callback, cioè nessuna WindowProc... si usano quelle già definite da User32 per le classi EDIT, BUTTON, ecc.

Se intendi le librerie .lib, no. Una libreria .lib è detta anche libreria "statica". Essa viene fisicamente inglobata all'interno di ogni .exe che ne fa uso. Quindi, concettualmente, è l'opposto di una libreria dinamica .dll.

AHI-AHI-AHI ennò non ci siamo...
ti confondi con semplici file COFF; un lib è diverso, ha tutt'altro formato e non è una libreria, ne' statica ne' dinamica. un COFF è una libreria statica, una DLL è dinamica. un lib serve solo in compile time per ritrovare informazioni di linking, statiche o dinamiche che siano.

[Gino+89+]

Ok..per fare finestre figlie faccio così:

IDD_DIALOG2 DIALOG 230, 0, 122, 68
STYLE WS_MINIMIZEBOX | WS_CHILD | WS_VISIBLE | WS_CAPTION | WS_SYSMENU
CAPTION "Non-modale"
FONT 8, "MS Sans Serif"
BEGIN
LISTBOX IDC_LIST1,10,5,105,60,LBS_NOTIFY | LBS_NOSEL | WS_VSCROLL | WS_HSCROLL | WS_TABSTOP
END

Se intendi le librerie .lib, no. Una libreria .lib è detta anche libreria "statica". Essa viene fisicamente inglobata all'interno di ogni .exe che ne fa uso. Quindi, concettualmente, è l'opposto di una libreria dinamica .dll.

Infatti intendevo .h, tipo una string.h per esempio...

La soluzione migliore, in genere, è quella di usare le dialog-box. Basta avere un editor delle risorse per poter "disegnare" la dialog e poi basta usare le funzioni DialogBoxXXX (modali) oppure CreateDialogXXX (non modali) più una tua funzione che faccia da "dialog procedure" e il grosso è fatto.

(No preferisco scrivermi le risorse manualmente con un semplice .rc...)
Si ok riesco a farli come dici tu...solo che non mi vengono tipo il grosso edit del BloccoNote di windozz...
Come vedi l'edit copre tutta la finestra principale e non può essere un dialogo visto che non presenta la barra del titolo:

Capito che intendo?...ripropongo la domanda: come posso fare un edit identico a quello del Blocco di windozz?

[andbin]

Originariamente inviato da 71104

be', ma poi per inserire bottoni e altri controlli nativi è più semplice perché non devi definire nessuna callback, cioè nessuna WindowProc... si usano quelle già definite da User32 per le classi EDIT, BUTTON, ecc.

Sì, però ammesso di voler usare esclusivamente CreateWindow(Ex), se vuoi creare 10 controlli, devi fare 10 chiamate a CreateWindow(Ex) ..... minimo una ventina di righe di codice, senza contare che ti devi dichiarare "a mano" (con delle #define) gli ID dei controlli e controllare, eventualmente, se ogni CreateWindow fallisce o meno.
Comodo no??

Originariamente inviato da 71104

AHI-AHI-AHI ennò non ci siamo...
ti confondi con semplici file COFF; un lib è diverso, ha tutt'altro formato e non è una libreria, ne' statica ne' dinamica. un COFF è una libreria statica, una DLL è dinamica. un lib serve solo in compile time per ritrovare informazioni di linking, statiche o dinamiche che siano.

Eh??? Ma hai bevuto ieri che era Domenica???
Una libreria .lib può essere certamente anche solo una "import library" (per agganciarsi ad una DLL) ma in generale una .lib (o .a su Linux) può contenere tutto il codice che vuoi!!! Funzioni, variabili.

[andbin]

Originariamente inviato da Gino+89+

Infatti intendevo .h, tipo una string.h per esempio...

No, i file .h come string.h sono solo gli include che contengono le dichiarazioni di macro, funzioni, strutture, ecc...
Ci sarà quindi una (o più, non lo so) libreria .lib che contiene le funzioni della libreria standard del "C".

Originariamente inviato da Gino+89+

solo che non mi vengono tipo il grosso edit del BloccoNote di windozz...

Perché la finestra principale del notepad non è sicuramente fatta come dialog-box!!! Visto che c'è 1 solo controllo (il campo di testo), hanno sicuramente usato l'approccio CreateWindow, ecc.... Come nell'esempio che avevo postato io.

[71104]

Originariamente inviato da Gino+89+

Il terzo modo non mi piace e l'ho scartato...

non lo sottovalutare: è il più produttivo dei 3.

capisco che tu abbia voglia di imparare roba di livello un po' più basso delle cazzatelle che ti insegnano a scuola (come non comprenderti, è la stessa voglia che ha sempre guidato anche me attraverso l'apprendimento di questa sconfinata scienza ), ma una volta che sei arrivato a toccare il fondo, cioè a capire a fondo cosa c'è "under the hood", vedrai che ti annoierai a riscrivere tutte le volte sempre le stesse cose per definire le window class, le WindowProc, le DialogProc, ecc.

per adesso continua ad imparare che fai bene, ma poi dovrai diventare più produttivo

per i primi due mi potresti fare un esempio pratico (magari con solo il pezzo di codice interessato) così prendo il più semplice?

uff ^^
non mi va di scrivere codice

nel primo caso: per creare una finestra che contenga un controllo nativo di Windows (casella di testo, pulsante, check box, radio button, list box, controlli di Internet Explorer...) basta che come nome della window class gli dai uno di quelli predefinit (qui hai l'elenco completo di quelli nativi, mancano quelli di IE: <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/windowing/windows/windowreference/windowfunctions/createwindow.asp>).

nel secondo invece devi solo disegnare la tua dialog nelle risorse e crearla con CreateDialogXxx passandogli la tua main window come Parent; e ovviamente, nel disegnare la dialog, devi toglierci la barretta blu e il contorno 3D in modo che resti solo un rettangolo grigio con dentro i controlli

Si li conosco, ma so solo implementarli in dialoghi separati, e quì si collega alla prima domanda visto che non so implementarlo a tutto schermo nella finestra principale..

distinguiamo il problema in due sottoproblemi:
1) creare l'edit nella main window; banale lavoro di CreateWindow, passando la stringa "EDIT" come window class name.
2) allinearlo alla client area (in modo che se ridimensioni la main window, l'edit la segue); qua non c'è scorciatoia, devi semplicemente gestire WM_SIZE nella finestra principale e ridimensionare l'edit con MoveWindow in modo che occupi l'intera client area della main window.

Quindi un dialogo modale potrebbre essere tipo una finestra figlia visto che se chiudo quella principale chiudo pure lui...no?

ennò, se è modale come fai a chiudere il padre visto che è disattivato proprio a causa della presenza di una dialog modale? una dialog modale può avere qualsiasi cosa come Parent e come Owner, è una normalissima finestra come le altre; ha solo la particolarità di essere gestita tramite una funzione bloccante DialogBoxXxx che ti impedisce di continuare il tuo normale loop di messaggi.

Si ho capito...tipo una libreria in poche parole no?...

si: DLL significa Dynamic Link Library. "Dynamic" è dovuto al fatto che una DLL può essere caricata e scaricata da un processo in fase di runtime, contrariamente ad una libreria statica che, una volta linkata all'eseguibile in fase di compilazione, non può più separarsene.

Magari all'università le tratteranno penso...o sbaglio...

si, ma dovrai aspettare parecchio: noi a Informatica a La Sapienza di Roma stiamo facendo le Win32 per la prima volta solo adesso al terzo anno. finalmente un esame in cui sono avvantaggiato

Edit: hai iniziato a 12-13 anni????...ma come hai fatto??...cos'è hai iniziato a programmare CUI a 7 anni??

no ^^ sono partito direttamente dalle GUI grazie a Delphi (strumento RAD semplicissimo da usare e nelle ultime versioni anche piuttosto potente), e usando Delphi mi è venuta la curiosità di sapere come erano implementate le sue librerie, VCL ed RTL. poi ho scoperto Visual C++ e a quel punto, avendo un'idea ben delineata di come si usano le API Win32 grazie ai miei hacking della VCL :P, ho iniziato a programmare in Win32 con C e C++. poi ho fatto il salto che ti ho descritto all'inizio del post: mi so rotto di scrivere sempre le stesse cose e sono passato a MFC/ATL (stupendissimi frameworks).
infine ho lasciato perdere del tutto la programmazione usermode per dedicarmi allo sviluppo di drivers :P
attualmente uso il DDK e sento la mancanza della programmazione a oggetti.

[Gino+89+]

1) creare l'edit nella main window; banale lavoro di CreateWindow, passando la stringa "EDIT" come window class name.
2) allinearlo alla client area (in modo che se ridimensioni la main window, l'edit la segue); qua non c'è scorciatoia, devi semplicemente gestire WM_SIZE nella finestra principale e ridimensionare l'edit con MoveWindow in modo che occupi l'intera client area della main window

Ah ora incomincio a capire...
"Creare l'edit nella main window"->ma è questo che non riesco a fare...
"passando la stringa "EDIT" come window class name."->Si bè ma solo per far capire che è un edit, anche se gli metto "pippo" non cambierebbe nulla no?

"banale lavoro di CreateWindow"->

CreateWindowEx(DWORD dwExStyle, // "stile esteso" 
                       LPCTSTR lpClassName, // nome della classe di finestra                                                                                                                                                                                                                           
                       LPCTSTR lpWindowName, // testo della finestra 
                       DWORD dwStyle, // stile della finestra 
                       int x, int y, int nWidth, int nHeight, // geometria 
                       HWND hWndParent, // finestra-genitrice 
                      HMENU hMenu, // menu, o identificatore di controllo 
                      HINSTANCE hInstance, // "istanza" del creatore 
                      LPVOID lpParam // puntatore a "dati supplementari" 
);

Dove?

[71104]

Originariamente inviato da andbin

Eh??? Ma hai bevuto ieri che era Domenica???

dammi del nerd quanto ti pare, ma io non mi sono mai ubriacato in tutta la mia vita

Una libreria .lib può essere certamente anche solo una "import library" (per agganciarsi ad una DLL) ma in generale una .lib (o .a su Linux) può contenere tutto il codice che vuoi!!! Funzioni, variabili.

non sapevo...

fermo rimane che ti confondevi coi file COFF: sarà che ho attivato qualche switch strano del compilatore, ma quando ho creato una mia libreria statica il .lib da solo per linkare non bastava.

[Gino+89+]

Ha ok scusa ora ho capito...non avevo letto bene la prima parte...grazie mille a tutti!!

[andbin]

Ecco il codice per un semplice e minimale editor di testo.

#define STRICT
#include <windows.h>
#include <commctrl.h>

#define MAIN_WNDCLASS   "ClasseEditorTesto"

#define IDC_EDIT        100

LRESULT CALLBACK Main_WndProc (HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
    switch (uMsg)
    {
        case WM_CREATE:
            return 0;

        case WM_PAINT:
        {
            HDC hdc;
            PAINTSTRUCT ps;

            hdc = BeginPaint (hWnd, &ps);

            EndPaint (hWnd, &ps);
            return 0;
        }

        case WM_DESTROY:
            PostQuitMessage (0);
            return 0;

        case WM_CLOSE:
            DestroyWindow (hWnd);
            return 0;

        case WM_SIZE:
        {
            INT iWidth = LOWORD (lParam);
            INT iHeight = HIWORD (lParam);

            SetWindowPos (GetDlgItem (hWnd, IDC_EDIT), NULL, 0, 0, iWidth, iHeight, SWP_NOZORDER | SWP_NOMOVE);
            return 0;
        }
    }

    return DefWindowProc (hWnd, uMsg, wParam, lParam);
}


INT APIENTRY WinMain (HINSTANCE hInstance, HINSTANCE hPrevious, LPSTR lpszCmdLine, INT iCmdShow)
{
    WNDCLASSEX  wcx;
    HWND        hWnd, hWndEdit;
    MSG         msg;

    wcx.cbSize        = sizeof (wcx);
    wcx.style         = CS_HREDRAW | CS_VREDRAW;
    wcx.lpfnWndProc   = (WNDPROC) Main_WndProc;
    wcx.cbClsExtra    = 0;
    wcx.cbWndExtra    = 0;
    wcx.hInstance     = hInstance;
    wcx.hIcon         = NULL;
    wcx.hIconSm       = NULL;
    wcx.hCursor       = LoadCursor (NULL, IDC_ARROW);
    wcx.hbrBackground = (HBRUSH) (COLOR_WINDOW+1);
    wcx.lpszMenuName  = NULL;
    wcx.lpszClassName = MAIN_WNDCLASS;

    if (!RegisterClassEx (&wcx))
    {
        MessageBox (NULL, "Errore nella registrazione della classe",
                    "ERRORE", MB_OK | MB_ICONEXCLAMATION);
        return 1;
    }

    hWnd = CreateWindow (MAIN_WNDCLASS, "Editor di testo", WS_OVERLAPPEDWINDOW,
                         CW_USEDEFAULT, 0, 300, 300,
                         NULL, NULL, hInstance, NULL);

    if (hWnd == NULL)
    {
        MessageBox (NULL, "Errore nella creazione della finestra",
                    "ERRORE", MB_OK | MB_ICONEXCLAMATION);
        return 1;
    }

    hWndEdit = CreateWindow (WC_EDIT, "", WS_CHILD | WS_VISIBLE | WS_VSCROLL |
                             WS_HSCROLL | ES_LEFT | ES_MULTILINE | ES_NOHIDESEL,
                             0, 0, 0, 0,
                             hWnd, (HMENU) IDC_EDIT, hInstance, NULL);

    if (hWndEdit == NULL)
    {
        MessageBox (NULL, "Errore nella creazione del campo di testo",
                    "ERRORE", MB_OK | MB_ICONEXCLAMATION);
        return 1;
    }

    ShowWindow (hWnd, SW_SHOWNORMAL);
    UpdateWindow (hWnd);

    while (GetMessage (&msg, NULL, 0, 0))
    {
        TranslateMessage (&msg);
        DispatchMessage (&msg);
    }

    return 0;
}

Se ridimensioni la finestra principale, tramite il codice che gestisce WM_SIZE ridimensiona anche il campo di testo!

[andbin]

Originariamente inviato da 71104

dammi del nerd quanto ti pare, ma io non mi sono mai ubriacato in tutta la mia vita

'na battuta ... dai!
Neanche io "bevo".

Originariamente inviato da 71104

fermo rimane che ti confondevi coi file COFF: sarà che ho attivato qualche switch strano del compilatore, ma quando ho creato una mia libreria statica il .lib da solo per linkare non bastava.

No, non c'entra nulla il formato COFF.
Indipendentemente dal suo formato interno, una libreria statica (.lib su Windows o .a su Linux), può, in generale, contenere N file .obj/.o.

[71104]

Originariamente inviato da andbin

No, non c'entra nulla il formato COFF.
Indipendentemente dal suo formato interno, una libreria statica (.lib su Windows o .a su Linux), può, in generale, contenere N file .obj/.o.

AAAAAAAAAAAAAAAAA e mo' ho capito!!

comunque io linkavo senza il lib, direttamente il COFF (ce n'era uno solo perché c'era un solo file sorgente; ce ne fossero stati più d'uno era conveniente metterli tutti dentro il lib e linkare solo quello, poi il compilatore lo apriva e linkava un COFF alla volta, dico bene?)

[71104]

Originariamente inviato da Gino+89+

Ah ora incomincio a capire...
"Creare l'edit nella main window"->ma è questo che non riesco a fare...
"passando la stringa "EDIT" come window class name."->Si bè ma solo per far capire che è un edit, anche se gli metto "pippo" non cambierebbe nulla no?

no: se metti "EDIT" o "pippo" o "pluto" al parametro lpWindowName non cambia nulla (cambi il testo dell'edit), ma al parametro lpClassName cambia eccome: "EDIT" è una window class creata da User32 la cui WindowProc implementa appunto le caselle di testo, pronte all'uso con tanto di cursore lampeggiante, inserimento testo in ANSI o Unicode, context menu con gestione della clipboard, scroll bars automatiche, mascheramento passwords, gestione del wrapping del testo, e chi più ne ha più ne metta.

[Gino+89+]

Originariamente inviato da 71104

no: se metti "EDIT" o "pippo" o "pluto" al parametro lpWindowName non cambia nulla (cambi il testo dell'edit), ma al parametro lpClassName cambia eccome: "EDIT" è una window class creata da User32 la cui WindowProc implementa appunto le caselle di testo, pronte all'uso con tanto di cursore lampeggiante, inserimento testo in ANSI o Unicode, context menu con gestione della clipboard, scroll bars automatiche, mascheramento passwords, gestione del wrapping del testo, e chi più ne ha più ne metta.

Mene sono accorto a mie spese quando cercavo di fare andare al code di andbin con nome della window class "EDIT" ...

Che cosa contiene commctrl.h di importante??...quando non lo includo mi da errore sul SetWindowPos()...

[andbin]

Originariamente inviato da Gino+89+

Che cosa contiene commctrl.h di importante??...quando non lo includo mi da errore sul SetWindowPos()...

Premetto che il codice che ho scritto si può sicuramente migliorare. L'ho scritto pochi minuti prima di uscire dall'ufficio e quindi di fretta.

Tecnicamente sarebbe più corretto creare il campo di edit (e in generale tutti i controlli) in risposta al messaggio WM_CREATE, perché in questo modo se la creazione di un controllo fallisce, si può far fallire la creazione della finestra principale restituendo -1 invece di 0.

Ho incluso commctrl.h perché in quel include c'è la definizione di WC_EDIT, che è una semplice macro per la stringa "Edit" (il nome della classe per il campo di edit).
Strano poi che ti dia errore sulla SetWindowPos se non lo includi. SetWindowPos non ha nulla a che vedere con i commctrl.h!!!

[andbin]

Originariamente inviato da 71104

comunque io linkavo senza il lib, direttamente il COFF (ce n'era uno solo perché c'era un solo file sorgente; ce ne fossero stati più d'uno era conveniente metterli tutti dentro il lib e linkare solo quello, poi il compilatore lo apriva e linkava un COFF alla volta, dico bene?)

Non capisco perché continui a parlare di COFF. COFF è solo uno dei formati per i file oggetto. Microsoft usa il formato COFF, Borland usava (o usa tuttora, non so com'è per gli ultimi tools sfornati) il formato OMF. Ma la questione non cambia.

Una libreria statica .lib/.a è generalmente un "contenitore" per più file oggetto. I vari compilatori mettono sicuramente a disposizione un tool per lavorare con le librerie statiche, per aggiungere/togliere/elencare, ecc... gli oggetti.