View Full Version : Aiuto sulle Api (nozioni di base)
Gino+89+
01-10-2006, 21:13
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...
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 :D
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+
02-10-2006, 15:45
Prima di tutto grazie per le risposte
ottima domanda, poiché la risposta è che in maniera veloce non si può; hai 3 modi:
1) li crei manualmente di sana CreateWindow :D
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? :D (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??
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? :D (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> (http://www.hwupgrade.it/forum/showthread.php?t=1167173) thread avevo postato un esempio completo per creare una finestra vuota (senza controlli). Guarda solo quanto codice serve per aprire una finestra vuota!
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.
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
02-10-2006, 16:12
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...
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... :asd:
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+
02-10-2006, 16:30
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:
http://www.hostingfiles.net/files/20061002052735_ImmagineNote.jpg
Capito che intendo?...ripropongo la domanda: come posso fare un edit identico a quello del Blocco di windozz?
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?? :D :D
AHI-AHI-AHI ennò non ci siamo... :asd:
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. :confused: :mbe: :mbe:
Eh??? Ma hai bevuto ieri che era Domenica??? :D
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.
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".
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.
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? :D uff ^^
non mi va di scrivere codice :p
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 :p
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+
02-10-2006, 16:54
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?
:confused: :mbe: :mbe:
Eh??? Ma hai bevuto ieri che era Domenica??? :D dammi del nerd quanto ti pare, ma io non mi sono mai ubriacato in tutta la mia vita :O :O :O
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. :mbe: 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+
02-10-2006, 17:20
Ha ok scusa ora ho capito...non avevo letto bene la prima parte...grazie mille a tutti!!
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!
dammi del nerd quanto ti pare, ma io non mi sono mai ubriacato in tutta la mia vita :O :O :O'na battuta ... dai! ;)
Neanche io "bevo". :)
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.
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!! :D :sofico:
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?)
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+
02-10-2006, 18:17
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" :D ...
Che cosa contiene commctrl.h di importante??...quando non lo includo mi da errore sul SetWindowPos()...
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!!!
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.
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.