Cairo, Windows (o Aros!) e visualizzazione superfici da png

Riassumiamo: ho scritto Comics. Per chi non sa cos'è è un cbr/cbz viewer, l'unico, su amiga ng (Aros, mos, os4). Usavo lo scaling immagini di libjpg fighissimo, ma per le png ovviamente non funziona, per cui sono passato alle funzioni native aros, pessime. Ora sto cercando di capire cosa usare per il rendering. Sono approdato a cairo (col quale ho avuto un fugace amore tempo fa). Cairo è una libreria opensource appunto di grafica, ma è cessonamente linuxiana e per di più (orribile!) orientata a python e gtk (schifo!). Per chi come noi non vuole usare python bensì il c e niente gtk ma robe native (basta linux) sorge un problema. Come creare una superfice? e fin qui ci viene in aiuto la versione nativa (ad esempio win32) con le sue api. Solo che non visualizza nessuna png. Come visualizzare una png sotto win con cairo? Semplice: Ecco un pò di codice case WM_PAINT: int w,h; hDC = BeginPaint(hwnd, &Ps); GetClientRect(hwnd,&ClientRect); //con questo creo la source surface dalla png che carico surface = cairo_image_surface_create_from_png ("pippo.png"); //con questo creo la surface destinazione dall'hdc di finestra (win32) destsurface=cairo_win32_surface_create(hDC); //vabbè prendo le dimensioni w = cairo_image_surface_get_width (surface); h = cairo_image_surface_get_height (surface); //creo il cr per la visualizzazione cr = cairo_create(destsurface); //scalo, ma se non vi piace scalare amen. A me serve questo cairo_scale (cr, 233.3/w, 166.0/h); //qui copio le due superfici: aggancio la surface source al cr della finestra che nel frattempo ha un suo destsurface, a partire da 0,0. cairo_set_source_surface (cr, surface, 0, 0); //DISEGNO! olè! cairo_paint (cr); //distruggo tutto... cairo_surface_destroy (surface); cairo_destroy(cr); break; // ciao!

Morphos sdl?

su morphzone mi rispondono che non c’è maniera. ho fatto un tentativo… la funzione SDL_GetWMInfo permette di ottenere informazioni dal windows manager in relazione alla finestra. Usa una struttura SDL_SysWMinfo che viene riempita con le opportune informazioni. Nel file sdl_syswm.h la struttura in questione ha una definizione diversa a seconda del sistema operativo. A titolo di esempio quella di windows è questa. typedef struct SDL_SysWMinfo { SDL_version version; HWND window; /**< The Win32 display window */ HGLRC hglrc; /**< The OpenGL context, if any */ } SDL_SysWMinfo; E’chiaro che se ho l’HWND ho tutto ciò che mi serve. Ci ho provato in passato e tutto funzionava alla perfezione: menu, gadget, barre varie etc. Con aros e gli altri sistemi amiga non c’è una vera definizione. Si usa la struttura generica che è questa: /** The generic custom window manager information structure */ typedef struct SDL_SysWMinfo { SDL_version version; int data; } SDL_SysWMinfo Mi sono detto: chissà ora faccio una bella fprintf %p del valore restituitomi in data e vediamo cosa succede. Ho verificato con scout per verificare che la finestra del mio programma abbia effettivamente l’indirizzo che mi riporta “data” ma niente. Il dato che mi riporta data è sempre diverso da qualsiasi indirizzo di finestra riportato da scout di aros… A questo punto ipotizzo che sdl di aros (morphos) non abbia una versione implementata di questa funzione? O sbaglio io qualcosa? Evidentemente il sistema operativo fornisce un altro sistema per il recupero dell’indirizzo di una finestra (scout da qualche parte lo deve prendere). Riformulo la domanda: laddove riuscissi in una qualche maniera a trovare l’indirizzo della finestra, ovviamente a runtime, c’è una possibilità di dire a mui che l’oggetto finestra che voglio è proprio quello con quell’indirizzo? In breve gli “monto” i gadget a finestra già creata…

Ancora Rebulator

e questo è l’ultimo su mui rebulator! non ho più continuato a scrivere perchè mi accorsi che il divertimento era passato: non lo facevo più per me ma mi rivolgevo a qualcuno quasi fosse una guida. continuai di lì a poco la stesura del prg che effettivamente funziona ma non ho più continuato la documentazione dello stesso nè lo studio di mui. devo dire che è questo è stato il primo progetto dopo anni che ho affrontato con passione. stavo imparando qualcosa di nuovo e mi è piaciuto molto. causa la mancanza di documentazione devo ringraziare in primis shinkuro per la sua guida. benchè affronti le tematiche in maniera forse troppo “oltre” per un neofita, in quel testo ti ritrovi sempre un qualcosa che poi ti fa passare oltre. così come gli autodoc di stuntz sono una vera e propria manna. per non parlare della più grande, disponibile e appassionata comunità di programmatori che conosca che è quella di morphos. 13/07/2011 Siamo a metà luglio e fa un caldo boia. Rebulator è andato avanti e i menu sono completi da un pò. In questi giorni sto affrontando l’uso dei font per i singoli oggetti. Qualcuno dirà: e che c’è da studiare sui font? Risposta: poi si vedrà… Ritornando ai nostri bravi menu… Come dicevo si tratta di creare la nostra menu strip e definire le nostre voci di menu, sottomenu e i loro attributi. Qualche tempo fa accennavo alla struttura newmenu. Cos’è nello specifico? E’una struttura che contiene “la descrizione” di tutte le singole voci di menu con gli attributi. L’uso di strutture per definire oggetti è una pratica che nasce “prima” dell’epoca degli oggetti. Non per niente, in mui, che è object oriented grazie a boopsi, è vero che si può usare la struttura NewMenu ma, contemporaneamente, si può usare anche la gestione diretta degli oggetti in tempo reale. Per carità ognuno ha o suoi gusti, io ho preferito optare per la seconda possibilità visto che MUI mi dava tale possibilità. Spiegheremo anche la NewMenu ma prima parleremo dell’implementazione dei menu di rebulator alla maniera di MUI. Riporto un frammento di codice che definisce i menu in rebulator 0.4: La prima riga crea l’oggetto menustrip (notare il cast verso IPTR sennò Gcc rompe) MUIA_Application_Menustrip, (IPTR)(MenustripObject, La seconda crea invece il primo menu come oggetto Child della classe family (MUIA_Family_Child). MUIA_Menu_Title come dice il nome imposta il nome del menu MUIA_Family_Child,(IPTR)(MenuObject,MUIA_Menu_Title, “Rebulator”, Qui, sempre come oggetto child, creiamo (MUI_MakeObject) un Menuitem (cioè una voce di menu) a nome “About, che abbia come lettera di tastiera per selezionarlo (con il tasto amiga) la lettera “A” e che non abbia altre particolarità (0,0) a questo associo una variabile oggetto “infomenu” MUIA_Family_Child, (IPTR)(infomenu = MUI_MakeObject(MUIO_Menuitem,”About”, “A”, 0,0)), Idem qui:creo una voce di menu Quit associata a un oggetto quit. MUIA_Family_Child, (IPTR) (quit = MUI_MakeObject(MUIO_Menuitem, “Quit”, “Q”,0,0)), Lo end chiude “il menu object”: i menu item non hanno bisogno di end!! End), Secondo menu chiamato Tools! MUIA_Family_Child, (IPTR) (MenuObject, MUIA_Menu_Title, “Tools”, Oops… ma come? prima di chiudere con un End il menu Tools aggiungo, non un menu item, bensì un altro oggetto menu (menuobject) chiamato keys? Ebbene si: inserire un oggetto menu in un altro oggetto menu è la maniera di MUI per creare… I SOTTOMENU!!! Niente di più semplice ma non so quanto tempo ho penato per capirlo (giuro per puro caso) Non c’è scritto da nessuna parte nella documentazione se non buttato la, in maniera peraltro semplicistica, nell’introduzione al capitolo dei menu. Roba che io le introduzioni non le leggo manco di solito… MUIA_Family_Child, (IPTR) (MenuObject, MUIA_Menu_Title, “Keys”, Qui riprende il flusso congeniale: un menu item per il nostro menu!! il suo titolo è base ed è associato all’oggetto “menu_standard”, ed ha alcune particolarità: 1) possiede l’attributo MUIA_Menuitem_Checkit, TRUE: serve a dire che la voce di menu è “checkabile”, cioè il click su di esso fa apparire un segno di spunta vicino al suo nome (per impostare qualcosa…) 2) MUIA_Family_Child,(IPTR) (menu_standard = MenuitemObject, MUIA_Menuitem_Title, (IPTR)”Base”, MUIA_Menuitem_Shortcut, (IPTR) “b”, MUIA_Menuitem_Checkit, TRUE, MUIA_Menuitem_Checked, TRUE, MUIA_Menuitem_Exclude, 2+4+8, End), MUIA_Family_Child,(IPTR) (menu_extended = MenuitemObject, MUIA_Menuitem_Title, (IPTR)”+Extended”, MUIA_Menuitem_Shortcut, (IPTR) “x”, MUIA_Menuitem_Checkit, TRUE, MUIA_Menuitem_Exclude, 1+4+8, End), MUIA_Family_Child, (IPTR) (menu_trigonometric = MenuitemObject, MUIA_Menuitem_Title, (IPTR)”+Trigonometric”, MUIA_Menuitem_Shortcut, (IPTR) “t”, MUIA_Menuitem_Checkit, TRUE, MUIA_Menuitem_Exclude, 1+2+8,End), End), End), End), Rispondi Citazione Attiva notifiche Rimuovi 835 LINGUAGGI – PROGRAMMAZIONE. / RE: [C][MUI]REBULATOR: A TROLL CALCULATOR… PENSIERI SPARSI « il: 16 Settembre 2011, 15:57:15 » chiaramente preso da manie di protagonismo, riporto gli ultimi uno o due post che avevo scritto sul mio blog riguardo rebulator. questa calcolatrice che sa fare un pò tutto e di fatto non sa fare il resto di niente!!!so che non potevate vivere senza… 23/06/2011 0.4! La principale novità della 0.4 rispetto alla 0.3 è l’introduzione dei menu. Certo, anche la correzione di alcuni bug (chiamarli così è riduttivo) è importante, ma l’introduzione dei menu è quel che mi ha portato ancora avanti nello studio di mui. Vediamo… Ovviamente tutti sappiamo cosa siano i menu in un programma: sono quelle liste di alimenti cucinati più o meno male a cui è associato un prezzo più o meno spropositato. Ennò… non è proprio così! I menu sono uno degli elementi fondamentali dei sistemi operativi a finestre e, anzi, a volte la posizione, il comportamento degli stessi definisce un pò tutto l’aspetto del sistema operativo. Prendete per esempio i vari sistemi amigoidi: tutti hanno la barra dei menu in alto con menu che si sviluppano verso il basso da sinistra verso destra. Stessa storia per i sistemi apple o per windows fino alla 3.x. Da win 9x in poi (ma già su nt) la barra menu principale è posta in basso e si sviluppa verso l’alto. Un’altra caratteristica peculiare dei sistemi amiga (e dei sistemi apple…) è che i programmi non hanno menu perennemente visibili ma divengono visibili con la pressione del tasto destro del mouse. In windows invece ogni programma ha la barra menu che fa parte della finestra del programma stesso ed è sempre visibile. Anche se a vedere windows 7 le cose stanno cambiando anche lì (prendete office o ie9). Ritorniamo ad amiga: Su amiga (eventualmente anche per MUI) per poter usare dei menu in un programma bisogna definire una struttura NewMenu che contiene tutti i dati necessari per il comportamento dei menu del programma. L’insieme di tutti i menu del programma vengono chiamati “menu strip”. Tradotto letteralmente significa striscia di menu: se teniamo presente come è strutturato un insieme di menu, cioè l’uno affianco all’altro con i propri sottomenu, la definizione di striscia è visivamente azzeccata. Quindi abbiamo questa striscia di menu. Composta di menu. I quali a loro volta sono composti di elementi singoli o di ulteriori sottomenu: MENUSTRIP -MENU1 —MENUITEM1.1 —MENUITEM1.2 —SUBMENU1.3 ——MENUITEM1.3.1 ——MENUITEM1.3.2 -MENU2 —MENUITEM2.1 —SUBMENU2.2 —–MENUITEM2.2.1 —–MENUITEM2.2.2 —–MENUITEM2.2.3 —MENUITEM2.3 Quello precedente è lo schema di una menustrip con due menu principali (menu1 e menu2), Menu1 ha due elementi (item) menuitem1.1 e menuitem1.2, nonchè un sottomenu (submenu1.3). Submenu1.3 ha due elementi menuitem1.3.1 e menuitem1.3.2. Lo stesso vale per menu2. P.S. la numerazione è qualcosa di messo da me e non fa parte nè del linguaggio nè di niente, serve solo per “dividere” i menu logicamente sulla carta. Ma non è imperativa. In MUI la classe Menustrip (la barra menu) è una sottoclasse (sottoinsieme) della classe family. Dalla definizione che ne da Stuntz (per i nuovi arrivati è il creatore di MUI) las family.class è la classe di base per tutti quegli oggetti capaci di gestire liste di “oggetti figli”. E se ci riflettiamo un menu ha nelle sue voci e nei suoi sottomenu, figuratamente, dei figli. Tanto per iniziare MUI permette di definire una barra menu per l’applicazione o per la singola finestra. Quindi potremo avere un’applicazione composta da due finestre separate che ha due menustrip separate. Un altro attributo fondamentale per le menustrip è MUIA_Menustrip_Enabled: booleano. Se settato a true la barra menu è attiva (enabled) altrimenti risulta disattivata. Questo viene stabilito in fase di creazione della menustrip usando i seguenti attributi: MUIA_Application_Menustrip MUIA_Window_Menustrip La prima, come si intuisce creerà una barra menu globale all’applicazione mentre la seconda riga creerà una barra menu relativa alla singola finestra nella quale sarà referenziata. In rebulator ho usato la MUIA_Application_Menustrip ma vale anche per la MUIA_Window_Menustrip. La riga MUIA_Application_Menustrip, (IPTR) (MenustripObject, crea le basi dell’oggetto MenuStrip. Nello specifico MenuStripObject è una define (contenuta come al solito in mui.h). Riporto di seguito le quattro define che riguardano i menu #define MenustripObject MUI_NewObject(MUIC_Menustrip #define MenuObject MUI_NewObject(MUIC_Menu #define MenuObjectT(name) MUI_NewObject(MUIC_Menu,MUIA_Menu_Title,name #define MenuitemObject MUI_NewObject(MUIC_Menuitem

Morphos Addicted

letteralmente drogato da morphos. l’ho letto da qualche parte su qualche sito. si addice perfettamente a me. sono arrivato al punto di temere la rottura del mac mini e addirittura di comprarne un secondo. poi mi dico che è meglio aspettare la 3.0 e vediamo che macchine supporta… Che devo dire: mi prende in maniera mostruosa. E’fatto bene, veramente bene, mostruosamente bene. L’unica cosa che non mi piace di morphos sono i vari temi. Quel che mi piace è amiga25. Anche ofour non è male. In questo bisogna dire che il più bel tema per sistemi amiga è quello di os4. Sicuramente non amo ferox anche se tra i builtin è il migliore. @jamballah: il tema che mostri nelle preferenze di polynet ng qual’è? è molto carino! Ritornando invece a morphos devo dire che fa tutto quel che gli è richiesto e anche oltre. In queste due settimane è stato costretto a un riavvio causa penna usb. Inserita, staccata senza particolari procedure e risultava come “bloccata”. Ho reinserito la penna, ho cliccato su espelli e lì il sistema è andato in freeze. Ma, devo dire, il sistema per il resto si comporta egregiamente. Cosa ci fai con morphos? Attività principale navigazione e visione di video su youtube. A volte scrittura di testi e programmini. Giochi poco e niente perchè non ce ne sono che amo. Diciamo che ormai sono pochi i giochi che mi prendono e sono da super next gen. Oppure da minimo minimo. Ma sicuramente non platform sdl. A proposito: ho installato osx in dual boot, con morphos che mi parte di default. Ho scoperto inoltre un pò di cosette del sistema “amiga” di cui non avevo idee e mi rendo conto, lavorando anche con aros, di quanto tutti questi figli di os3 abbiano tanto in comune. Ho installato un pò di mason icons (ancora una volta per i miei gusti il lato grafico del versante os4 è vincente) e sostituito alcune def_icons. Amiga ng… In questi momenti capisco un pò di più perchè ci siano dei pazzi che spendono cifre blu per comprarsi macchine a perdere. Non c’è nessun simil unix che può sostituire un sistema amigoso… Ma in questi momenti penso ancor più che ppc è una prigione per questo sistema operativo. Che dopo quasi 30 anni ha ancora tanto da dire.

Aros il Giovane

L’uomo vestito di grigio tolse il cappellaccio dalla sua testa e in tono teatrale disse: “Corvi neri all’orizzonte! Il giovane aeros ha in sè il potere di linux il vecchio e la velocità di suo fratello aros. Ma non ne ha la saggezza! Egli vuole essere schedulato e roccheggiante! Grande è la sua ambizione! Dalle sue azioni dipenderà la sopravvivenza del suo veloce ma gracile germano…” detto ciò si riaccomodò. Si alzò dal suo scranno la blu vestita sacerdotessa dell’Ordine della Farfalla. “Viandante, capisco le tue preoccupazioni ma credo che siano eccessive. Aeros ha una grande forza: la giovinezza. Porterà a noi nuovi amici! Giovani guerrieri e creature fantastiche: uccelli tonanti, volpi di fuoco e infine i cinque rossi!” disse quest’ultimo nome con accentuata drammaticità aspettando una reazione dalla platea. Come una furia si alzò il custode della tradizione: il custode della magica sfera bianco-rossa: “Scempio su di noi! Scempio su di noi che attraversiamo queste terre non meritandolo! Il custode dello schermo della morte starà solo ridendo di noi in questo momento! Affidiamo i nostri destini a un eretico! Affidiamo le nostre vite a un pervertito meticcio! Nel suo sangue scorre il sangue della bestia…” gesticolando con le mani continuava “ho scrutato la sua memoria… e ho visto… il marchio… il basso endian… voi tutti sapete di cosa parlo!” si rivolse con un sorrisetto verso il viandante “non dire che non sai di cosa parlo. anche tu ti sei contaminato” Il viandante si stava per alzare sfoderando la spada quando irruppe nella sala un giovane macilento quanto rapido. Nei suoi occhi cerchiati si vedeva una scintilla strana. Assomigliava in una maniera distorta al vecchio biancorosso vestito e anche alla sacerdotessa. Ma era diverso. “Sono io il corrotto!” disse lui “ma non potete negare che il mio sangue è anche il vostro” “Perfino tu!” rivolto al custode della sfera porti con te il tuo famiglio, indicando con mano malferma un cigno assomigliante in maniera innaturale a un pinguino. Il viandante si avvicinò al ragazzo e lo sorresse: “hai ragione aros ma non capisci. aeros è pericoloso! va fermato! non ci porterà altri amici. Quando vedranno la sua potenza e la tua velocità penseranno che sei tu. Siete indistinguibili… molti abbandoneranno la causa…” Il giovane sottrasse il suo braccio alla presa del viandante “STO CAXXO CHE SIAMO UGUALI. QUELLO C’HA DELLE SCHIFOSISSIME ICONE TIPO OSX PERCHE’ IL TIPO CHE L’HA FATTO E’UNO CHE CI PIACIONO LE MELE FRADICIE!” Detto questo svenne. “Era in trance! Era in trance! Ha avuto un messaggio dall’Altissimo!” esclamò la sacerdotessa bluvestita. In quel clima di perplessità ognuno si interrogava se il vecchio viandante non avesse avuto ragione…

Su cosa lavori?

Su aros-exec c’è un topic: what are you working to? Bene, questa ne è la versione povera. Perchè in realtà sono quelle cose alle quali mi dedico a tempo perso e, troppe insieme, quindi difficilmente se ne finisce una. 1) comic reader per windows ce in c#: ti devi studiare le zlib e sicuramente qualche altra schifezza per aprire zip e rar. e quindi studiarti il formato zip e il formato rar… ma poi perchè non lo posso fare in c? perchè devo morire. 2) videoscrittura: abbandono delle sdl in favore di cairo o freetype. debugging delle funzioni di impaginazione (almeno qua ormai si vede la luce). fare prove con font multipli. collegamento con mui o intuition per farlo funzionare sotto un sistema amigoide. tenere conto nelle funzioni di impaginazione così ci mettiamo pure le immagini dentro! 3) morphos: completare il tema os4.1. è odioso e noioso ritagliare pezzi di immagine. 4) imparare a usare il make. sono sicuro che quando l’avrò imparato non mi servirà a una mazza 5) imparare c#. non mi serve a una mazza ma non si sa mai. 6) buttare giù un gioco di avventura. ho iniziato la videoscrittura proprio per un gioco di avventure testuali a schermate fisse. ora che la parte principale è pronta non ho più voglia di buttare giù il gioco. in compenso ho scelto la colonna sonora: wagner. la caduta degli dei. ah si—>7) 7) imparare a usare un programma per presentazioni così faccio l’intro. prima o poi mi butto giù qualcosa. avevo un’idea sul vampiro di polidori ma non mi sento ispirato. non lo ricordavo bene e mi sa che ho fatto confusione con carmilla di le fanu. 8) buttare giù un programma di musichette touch per windows ce 9) allungare le ore della giornata…

Cairo o Freetype?

Sempre per il mio progettino di videoscrittura, partito con sdl_ttf, devo prendere una decisione: cairo o freetype? Cairo ha il grande vantaggio di essere portabile, esiste su aros e morphos e ha anche funzioni di disegno incorporate per i font. Freetype è sicuramente più veloce ma dovrei poi implementare funzioni di disegno diverse per sistemi diversi. Io programmo sotto windows e poi compilo sotto aros (laddove necessario). Con sdl il grande vantaggio era che quel che funzionava sotto windows funzionava uguale sotto aros senza modifiche. Sorge inoltre un altro problema: abbandono sdl perchè non si può interfacciarlo con i gadget di mui senza stravolgere sdl stesso o ricorrere a dei trick strani e mui vuole che la finestra sia creata con mui. Freetype chiaramente ha il vantaggio che la finestra se la crea mui e nessuno gli rompe le scatole. Cairo invece? Ho letto stamane un tutorial. Si parlava di “superfici” e la cosa mi ha disturbato non poco. Non è che finisce che mi va a creare lui le finestre e quindi non mi interfaccio con mui? Grazie!! edit: ma cairo che fa????? gli unici esempi che trovo sono appoggiati a gtk:|:|:| sotto windows di fatto che si fa? mi rimpiazza semplicemente le gdi? ok. capito come funziona sotto windows. la portabilità sta nel fatto che “sono le api di disegno che lo sono” la finestra me la creo come il sistema operativo vuole e (esempio in windows) mi limito a passargli i puntatori necessari per le superfici della finestra nella chiamata a on paint. la velocità sembra discreta. un ciclo di pittura di 800*600 rettangoli a schermo mi è sembrato decentemente veloce. Alla fine io devo disegnare caratteri e ridisegnare continuamente le zone variate. Non arriverò mai a dover disegnare in blocco 480000 caratteri. se prendo uno schermo 1280*1024 usando come esempio un piccolo carattere box di 100 pixel (10*10) otterrei circa 13.000 caratteri. Su un 1600*1200 arriverei a 19200 caratteri. Diciamo che le prestazioni sono buone. Per ora vince cairo 1 a 0… Il passo successivo sarà di vedere sotto aros come si comporta. A questo punto mi dovrò creare la mia brava finestra e vedere come interfacciarlo con cairo. Leggevo che sotto morphos è stato usato per webkit (quindi owb??)… sperem… aggiungo a titolo di esempio il codice per la realizzazione di un rettangolo #include #include #include #include /* Declare Windows procedure */ LRESULT CALLBACK WindowProcedure (HWND, UINT, WPARAM, LPARAM); /* Make the class name into a global variable */ char szClassName[ ] = “CodeBlocksWindowsApp”; int WINAPI WinMain (HINSTANCE hThisInstance, HINSTANCE hPrevInstance, LPSTR lpszArgument, int nCmdShow) { HWND hwnd; /* This is the handle for our window */ MSG messages; /* Here messages to the application are saved */ WNDCLASSEX wincl; /* Data structure for the windowclass */ /* The Window structure */ wincl.hInstance = hThisInstance; wincl.lpszClassName = szClassName; wincl.lpfnWndProc = WindowProcedure; /* This function is called by windows */ wincl.style = CS_DBLCLKS; /* Catch double-clicks */ wincl.cbSize = sizeof (WNDCLASSEX); /* Use default icon and mouse-pointer */ wincl.hIcon = LoadIcon (NULL, IDI_APPLICATION); wincl.hIconSm = LoadIcon (NULL, IDI_APPLICATION); wincl.hCursor = LoadCursor (NULL, IDC_ARROW); wincl.lpszMenuName = NULL; /* No menu */ wincl.cbClsExtra = 0; /* No extra bytes after the window class */ wincl.cbWndExtra = 0; /* structure or the window instance */ /* Use Windows’s default colour as the background of the window */ wincl.hbrBackground = (HBRUSH) COLOR_BACKGROUND; /* Register the window class, and if it fails quit the program */ if (!RegisterClassEx (&wincl)) return 0; /* The class is registered, let’s create the program*/ hwnd = CreateWindowEx ( 0, /* Extended possibilites for variation */ szClassName, /* Classname */ “Code::Blocks Template Windows App”, /* Title Text */ WS_OVERLAPPEDWINDOW, /* default window */ CW_USEDEFAULT, /* Windows decides the position */ CW_USEDEFAULT, /* where the window ends up on the screen */ 544, /* The programs width */ 375, /* and height in pixels */ HWND_DESKTOP, /* The window is a child-window to desktop */ NULL, /* No menu */ hThisInstance, /* Program Instance handler */ NULL /* No Window Creation data */ ); /* Make the window visible on the screen */ ShowWindow (hwnd, nCmdShow); /* Run the message loop. It will run until GetMessage() returns 0 */ while (GetMessage (&messages, NULL, 0, 0)) { /* Translate virtual-key messages into character messages */ TranslateMessage(&messages); /* Send message to WindowProcedure */ DispatchMessage(&messages); } /* The program return-value is 0 – The value that PostQuitMessage() gave */ return messages.wParam; } /* This function is called by the Windows function DispatchMessage() */ LRESULT CALLBACK WindowProcedure (HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam) { HDC hDC; PAINTSTRUCT Ps; switch (message) /* handle the messages */ { case WM_DESTROY: PostQuitMessage (0); /* send a WM_QUIT to the message queue */ break; case WM_PAINT: int i,j; hDC = BeginPaint(hwnd, &Ps); // TODO: Add any drawing code here… cairo_surface_t *surface; cairo_t *cr; //FUNZIONE WINDOWS PER RESTITUIRE IL PUNTATORE DEL CONTESTO FINESTRA WIN32 PER CREARE //CONTESTO (LA SUPERFICIE) SULLA QUALE CAIRO DISEGNA surface = cairo_win32_surface_create(hDC); cr = cairo_create(surface); cairo_set_source_rgb (cr, 0, 0, 0); cairo_rectangle (cr, 20+i,20+j,120+i,80+j); cairo_fill (cr); cairo_destroy(cr); break; default: /* for messages that we don’t deal with */ return DefWindowProc (hwnd, message, wParam, lParam); } return 0; } uhuhhuhhhuhhhuhhhuh (risata scomposta) che bella cosa i file header. io mi dimentico sempre della loro esistenza… in cairo-aros.h cairo_public cairo_surface_t * cairo_aros_surface_create (struct RastPort *rastport, int xoff, int yoff, int width, int height); nella versione per morphos c’è anche un esempio. stasera mi sa che mi diverto un poco…