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…

Bug morti?

e non puzzano? mia moglie non credo sia molto d’accordo… cmq ne sto lasciando molti di morti… sto trasformando e ripulendo il codice e temporeggio… cacchio se temporeggio e rimando…. perchè leggendo un pò in più la guida di shinkuro ho deciso che dovrei leggermi un pò qualcosa sulla filosofia boopsi—> studiare ancora. Ora penso io ma non esiste un xxxxxxxx che produce un wordprocessor per amiga così che mi trovo un altro hobby??? Per carità è bellissimo mettersi lì e vedere crescere il codice man mano ma è parimenti avvilente realizzare qualcosa su una piattaforma che pensavi di conoscere e man mano che vai avanti ti rendi conto che conosci meno del meno. se poi si aggiunge che pensi che quel programma non lo userai mai. al massimo lo useranno 10 persone (100 considerando tutti gli amighisti del pianeta) il mio narcisismo viene a battere cassa. l’unica maniera per convincerlo a ripassare in altro momento a pretendere i suoi crediti è mostrargli la vera soddisfazione di ogni programmatore: i bug… vedere bug che nascono, crescono e si riproducono e pensare: hanno messo su famiglia grazie a me… in quei momenti mi sento molto padrone della bassa padana… Digressioni di solito funziona così: luce spenta. tutti dormono. si sente solo il rumore delle unghie sui tasti (causa chitarra classica) tipo segretaria. ogni tanto salto dalla sedia quando “la creatura” (il progetto) si muove. mi alzo. penso. giro intorno alla sedia o mi metto a pensare col naso incollato alla finestra. alle due di notte penso che caxxo ci starà a fare una luce accesa di fronte (dove per di fronte si intende un centinaio metri di distanza dal prossimo fabbricato). mi risiedo. controllo su google tutto quello che esiste sul nemico (il nemico è la libreria in oggetto: chi è, che fa e perchè lo fa). dopodichè bestemmio tutti i santi degli sviluppatori che hanno deciso che quella libreria gli fosse utile per un qualcosa. guardo un file make e lo guardo come si guarda uno scritto in arabo. solo che l’arabo è almeno esteticamente bello. capisco finalmente che @libs@ è una sorta di stringa di rimpiazzo. tipo: unire i puntini per costruire la figura. e io secondo loro dovrei mettermi a rimpiazzare una paginata di quei cosi? aspè ho letto che esiste un auto coso automake o giù di lì. farà questo? alla fine si è qualcosa di simile. da shell provo automake: non è un eseguibile. faccio una ricerca. è uno script in perl. proviamo a lanciarlo con perl. realizzo che il perl serve almeno a qualcosa. parte ma con una serie di errori. è vero avevo modificato i makefile… boh. domani rimetto quelli originali. adesso è tardi.se ne parla domani (cioè oggi). la programmazione (chiamiamola così) è un’esperienza totalizzante. una di quelle cose che paragono al modellismo con linguetta di fuori mentre incolli il pezzo minuscolo con la lente, piuttosto che la ripetizione della stessa battuta musicale per due ore consecutive. sai che l’hai studiata bene quando arriva l’urlo della moglie:EBBAASTAAAAAAAAAAAAAAA. non si sa se ce l’ha con me o col metronomo. (meglio del metronomo e sicuramente meno politically correct del maestro). Questo (non questa) è la programmazione. Una bella attività mentale. E faccio anche ginnastica intorno alla poltroncina girevole. Oltre che i fatti di quello “di fronte” alla fine ho vinto io contro l’infame!!! ho ricompilato cairo con supporto freetype:D:D ho disegnato dei caratteri freetype con cairo in una finestra mui. sicuramente non è chissà che risultatone ma se pensiamo che owb usa sdl per disegnarsi…. boh. io ho scritto su aros-exec. se è una cosa buona lo saprò a breve, sennò continuo con il mio progettino di videoscrittura. sicuramente posto le nuove cairo su aros archives e l’esempio sul wiki. “STO TUTT ECCITAT” ai che ero convinto che la versione aros usasse sdl? sarà che ho letto proprio ultimamente un post di nikolaos (quello di aspireos) che parlando dell’owb di fab, riporta le parole di quest’ultimo, il quale afferma che un port di owb morphos sarebbe più facile se si abbandonasse sdl in favore di cairo. cmq al di la di tutto ora ho la base per poter continuare i miei progettini:D Qualche nuovo progresso. Ho imparato qualcosa della dos library. Sono riuscito a caricare in un bel vettore di stringhe tutti i file ttf presenti in una data directory. Dopo aver buttato tonnellate di sangue mazze mi ha illuminato e ho scoperto che const char* ciao[] è equivalente a strptr array[] ai fini di un cycle object mui. Con mia somma gioia mi appresto a gestire un redraw della finestra e mi sovviene il fatto che mui non gestisca direttamente il resize gadget se non tramite programmazione a oggetti (kronos). Cosa che non voglio fare. Credo che nei prossimi giorni mi imbarcherò in una delle più schifose cose esistenti: mischiare messaggi mui e idcmp. Vedremo cosa ne uscirà… è passato un pò di tempo. abbandonata l’idea di fare miscugli alieni alla fine ho usato mui come vuole essere usato: istanziando degli oggetti. la cosa comoda è che non devi usare necessariamente l’oop. nel senso che un oggetto mui (cito shinkuro) è una struct del linguaggio c. nè più e nè meno. per le notifiche (la comunicazione interna all’applicazione) esiste una cosa magnifica che si chiama dispatcher: a sollecitazione a corrisponde azione b su oggetto c. saltata la fase degli hook perchè mi è aliena e mi sono buttato sull’implementazione di metodi custom (qualcuno direbbe ereditati). tutto ciò per scoprire che cairo non supporta i caratteri con diacritic (ad esempio un accento), piuttosto che il corsivo o il grassetto. anche usando freetype e fontconfig. se per il corsivo ho imparato pure le trasformazioni con le matrici… per il grassetto dovrei imparare a usare i pattern di fontconfig… e, a leggere dalle mailing list, non è detto che funzioni… non per niente spingono pango. le trasformazioni già mi bastano. ma studiare un ulteriore libreria per un grassetto mi sa che è eccessivo… ho visto in sdl_ttf che lantinga gestisce il grassetto modificando la bitmap in una qualche maniera. domani mi rubo un pò di codice… aggiornamento: non che se ne sentisse il bisogno ma così cerco di salire di grado scrivendo vaccate… abbandonato totalmente cairo. sto usando una libreria ttf interna trovata su aros-exec. nell’ultimo mese sono andato un pò a tentoni ma sono riuscito a trasformare l’applicativo che sta nascendo in un oggettone mui. la black box centrale riceve in ingresso un testo in un qualche formato simil richtext, lo trasforma in un suo formato interno, lo formatta, lo spara a video e chiaramente ne permette l’interazione. ho imparato a mie spese che per togliere la cera e mettere la cera bisogna usare i metodi di mui sennò si “piglia molta collera” e non funziona niente. assolutamente niente. ho imparato che per programmare sotto aros non solo devi morire ma anche oltre. non essendoci un ambiente di programmazione degno di questo nome, bisogna andare a tentoni: -1 scrivere -2 salvare -3 compilare -4 se va bene eseguire sennò ripetere da 1 -5 se va bene l’esecuzione ripetere da 1 e continuare ad aggiungere - 6 se si impalla il sistema isolare gli errori. Per isolare un errore sotto aros, come si fa? Si prende una mazza grossa e un elmetto da vichingo. Ci si precipita nel mucchio degli errori e spaventarli a morte finchè non hai quello che ti interessa e bastonarlo. I piccoli bastardi si nascondono sotto la mia scrivania… li sento… mi osservano… mi guardano e sorridono… Ma li fotto io. Li fotto! Quando sento quelle vocine che fanno “bug bug bug bug” ne schiaccio uno ed è una soddisfazione sentire il croc sotto la scarpa… Ovviamente scherzo. Sarei impazzito se veramente facessi questo. Per isolare un bug bisogna mettere una carota rossa e succosa fuori la sua tana e aspettare… aspettare… aspettare… Poi quando esce mettere un elmetto da vichingo e un grosso bastone… edit: se quei simpaticoni e facinorosi non l’avessero capito, shinkuro il portatile morphos o comunque IL PLAUSO DELLA COMUNITA’ se lo merita, non per aver scritto shadow of the beast iv ma per aver scritto L’UNICO DOCUMENTO VALIDO ESISTENTE SU MUI. Io poi vorrei sapere che killer app hanno realizzato gli altri… l’unico che poteva parlare era fab e non l’ho visto parlare.

rebulator3

MUIA_Text_SetVMax, FALSE, MUIA_InnerBottom, 0, MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, Gli ultimi 6 elementi riguardano tutti la “spaziatura” e il layout dell’oggetto bottone che rebulator implementa. Gli ultimi 3 in particolare sono commentati visto che alla fine non li ho usati. La mia esigenza era quella di creare per rebulator dei pulsanti che non avessero necessariamente tutti la stessa dimensione o lo stesso aspetto. MUI di suo tende a dividere lo spazio della finestra in oggetti di egual dimensione o comunque ad accomodare in maniera armonica gli oggetti su di essa. Non sempre però è ciò che si vuole: sulle calcolatrici il pulsante + o il pulsante = di solito sono più grandi degli altri così come il modello di rebulator, che è una calcolatrice cinese da tre soldi, ha i pulsanti della gestione memoria più piccoli rispetto agli altri. Come ottenere quindi pulsanti di dimensioni diverse pur rimanendo nell’ambito di un layout omogeneo? Le strade sono varie: creare gruppi ad hoc (ricordo che MUI permette di creare dei frame l’un dentro l’altro così da creare delle gabbie di oggetti ma non mi piace come cosa), così come giocare sugli attributi. Quelli presenti nelle righe che vedremo permettono un bel pò di personalizzazioni in merito: 1) MUIA_Text_SetVMax (BOOLEANO) Derivato dalla classe TEXT, è un attributo che stabilisce in un oggetto se l’altezza massima dello stesso sia limitata all’altezza del testo in essa contenuto. In pratica l’oggetto non potrebbe mai espandersi verticalmente se questo attributo avesse come valore TRUE In rebulator è settato a FALSE perchè Rebulator ha un layout liquido (non so manco cosa significhi lontanamente ma una volta in metro c’erano due fanatici di css che parlavano solo di questo così ho deciso che un giorno oltre a trovare indastria e liberare lana avrei creato qualcosa con un layout liquido): se si allarga la finestra anche i suoi pulsanti si devono allargare o allungare di conseguenza. Una delle prossime cose che studierò sarà come ingrandire i font in tempo reale. 2) MUIA_InnerBottom Definisce, in pixel, lo spazio che il sistema deve lasciare dal “bottom” cioè dalla base del testo alla cornice. Settandolo a 0 gli ho detto che non voglio pixel tra la base del testo e la cornice. Mi serviva per i tasti memoria per “schiacciarli” in altezza il più possibile 3) MUIA_InnerTop Idem come inner bottom. Solo che lo spazio stavolta è quello riservato sopra il testo. Settando a 0 questo attributo dico a MUI che non voglio spazio di pixel tra il testo e la cornice. 4) MUIA_FixHeightTxt E’commentato dunque non è attivo in rebulator. E’ un attributo che dice a MUI che l’altezza di quel determinato oggetto (height) debba essere fissata (fix) all’altezza del testo che gli si passa come valore (in questo caso MR). Utile per limitare l’altezza. Credo faccia a cazzotti con MUIA_Text_SetVMax, FALSE. 5) MUIA_FixWidth Anch’esso commentato. Attributo che riceve come valore il numero di pixel il cui valore rappresenta la larghezza dell’oggetto. Utile per delimitare la larghezza 6) MUIA_VertWeight Un argomento particolarmente interessante e importante di MUI sono i “pesi”. Dicevo che MUI cerca di organizzare il layout in maniera armonica. Come dice il termine, dando quindi a tutti gli oggetti un “peso” uguale o quantomeno quel giusto tot. Il peso di un oggetto è il meccanismo invece che MUI usa per alterare questo equilibrio. Il peso di un oggetto, inteso come spazio (verticale o orizzontale o entrambi) che l’oggetto deve occupare rispetto a ciò che normalmente gli sarebbe concesso in funzione del numero e tipo di oggetti presenti nel suo gruppo, è definito in “percentuale”. Se un oggetto deve occupare più del suo normale spazio avrà quindi un valore di attributo superiore a 100. Viceversa se ne deve occupare di meno sarà inferiore a 100. Un valore pari a 0 (laddove non produca dei bei crash di sistema:p) indica a MUI che l’oggetto deve occupare “sempre” il minimo dello spazio consentito. Ora gli attributi che si occupano di gestire il peso di un oggetto MUI sono 3: - MUiA_Weight: gestisce il peso dell’oggetto sia in verticale che in orizzontale. Esempio: MUIA_Weight, 300, significa che l’oggetto (in verticale e in orizzontale) occuperà il 300% del normale spazio. - MUIA_VertWeight: come prima ma regola solo il “peso” verticale (quindi lo spazio in altezza) dell’oggetto. - MUIA_HorizWeight: idem. Solo che abbiamo a che fare con il peso orizzontale. Perchè avevo messo tutto a 0? Semplicemente perchè volevo che i pulsanti di gestione memoria non fossero “armonici” ma fossero schiacciati. edit: ho l’impressione che il tipo di mui fosse abruzzese. questo mette in crisi diverse teorie Arriviamo adesso alle cose interessanti! Non che le altre cose non lo siano ma queste lo sono particolarmente. Precedentemente avevamo detto che in MUI un oggetto pulsante vero e proprio non esiste bensì esso altro non è che un oggetto derivato dalla classe AREA. Non l’avevamo detto? L’ho detto ora:D Cosa rende un pulsante tale? Una bella area (manco a farlo apposta) che se la clicco (di solito col pulsante sinistro del mouse) succede un qualcosa. MUI utilizza due attributi booleani (i primi due) e un attributo intero (con funzione di temporizzatore) per la gestione del pulsante sinistro del mouse nell’ambito della classe Area: 1) MUIA_Selected: è quell’attributo (vero o falso) dell’oggetto che ha a che fare con la sua selezione. 2) MUIA_Pressed: è quell’attributo (vero o falso) il cui valore ha a che fare con la pressione (o meno) del pulsante sinistro del mouse sull’oggetto 3) MUIA_Timer: è un temporizzatore che memorizza da quanto tempo il pulsante sinistro del mouse è premuto su un gadget bottone. Ora, la classe area ha nell’attributo MUIA_InputMode un importante strumento per definire il comportamento dei gadget BOTTONI et similia (non i bottoni del mouse proprio i gadget delle finestre. Tra bottoni, pulsanti e oggetti ci si confonde:P) In pratica gestisce, come suggerisce il nome, il comportamento di un oggetto di fronte all’input e (nello specifico) rispetto alla pressione del pulsante sinistro del mouse. Entrando più nel dettaglio MUIA_InputMode ha quattro possibili valori: MUIV_InputMode_None, MUIV_InputMode_Relverify, MUIV_InputMode_Immediate e MUIV_InputMode_Toggle. Ma che relazione hanno i valori di MUIA_InputMode e gli attributi sopra visti? Semplicemente, scegliendo uno dei valori di MUIA_InputMode, sceglieremo anche come il nostro oggetto si regolerà rispetto agli attributi MUIA_Selected, MUIA_Pressed e MUIA_Timer. Vediamo come: 1)MUIV_InputMode_None: come dice il none (non è abruzzese è inglese e significa nessuno) l’oggetto in questione non risponde agli input e quindi se ne frega alla grande di MUIA_Selected, MUIA_Pressed e MUIA_Timer 2) MUIV_InputMode_RelVerify: è il valore di default per i bottoni. - MUIA_Selected (ricordiamo che è un bool): vero quando il pulsante sx viene premuto su esso falso quando il pulsante sx viene rilasciato falso quando il gadget è selezionato ma il mouse esce dall’area dell’oggetto vero quando il mouse rientra nell’area dell’oggetto. In pratica definendo MUIV_InputMode_RelVerify come valore di MUIA_InputMode avremo scelto di associare all’oggetto in questione questi comportamenti. - MUIA_Pressed vero quando il pulsante sx viene premuto su esso (come MUIA_Selected: ovviamente se premo il pulsante sinistro lo sto anche selezionando) falso quando lascio il pulsante sx. Qui si aprono due strade: –se il mouse è ancora sull’oggetto si scatena una notifica. –se il mouse non è sull’oggetto all’atto del rilascio non si scatena una notifica. Perchè si scatena una notifica quando lascio il pulsante sinistro del mouse se il puntatore è ancora sull’oggetto? Beh, fateci caso. Quando premete il pulsante del mouse su un bottone non succede un bel niente. E’quando lo rilasciate che succede qualcosa. PRovare per credere!!:))) - MUIA_Timer: attributo long, come dicevamo si tratta di un temporizzatore che entra in funzione dopo che un bottone RelVerify è stato premuto e tiene conto del tempo di pressione del pulsante sx. Non l’ho ancora usato e quindi è da approfondire. 3)MUIV_InputMode_Immediate: è il valore che ha a che fare con i radio button e altri oggetti che, come dice il nome, hanno una reazione immediata alla pressione del mouse. Proprio a causa di questo suo modo di essere l’attributo MUIA_PRessed non è definito MUIA_Selected: si scatena non appena il pulsante sx viene premuto sull’oggetto 4)MUIV_InputMode_Toggle: è il valore degli oggetti come i check (toggle tradotto letteralmente significa togli e se volete ciò che si fa con i check è proprio togliere e metter quella benedetta x nella casellina) Anche qui MUIA_Pressed non ha senso. MUIA_Selected invece diventa falso quando si preme il pulsante sx del mouse (al contrario di MUIV_Input_Immediate). Ricordo sempre che con get e set c’è la possibilità di leggere e scrivere questi valori negli oggetti così da “forzare” la mano laddove necessario o reperire gli stessi! Ritorniamo alle decorazioni: Continuando nella descrizione del nostro pulsante, incontriamo la coppia attributo-valore MUIA_Background, MUII_ButtonBack, Come possiamo immaginare MUIA_Background è quell’attributo MUI che gestisce lo sfondo (background) di un oggetto. Lo sfondo di un oggetto è normalmente un’immagine e il nostro sfondo non fa eccezzione: il valore infatti è MUII_ButtonBack. Ricordiamo che MUII sta per MUI Image, cioè Immagine Mui. Valore che in questo caso è guarda caso ButtonBack, cioè sfondo per i bottoni. MUIA_Background assume diversi valori tutti da provare e vi rimando alla documentazione MUI a riguardo. Carina come cosa è quella di provare varie immagini per vari tipi di oggetto: siamo nell’ambito delle decorazioni e allora perchè non provare a cambiare? Se la vocina nel cervello vi dice: “per non confondere le cose!” Non ascoltatela! Provate provate provate. E poi fatemi sapere. Mi incuriosisce quello shine back.:p Alzi la mano chi ritiene il mouse senza tastiera utile. Il mouse senza tastiera è meno utile della tastiera senza mouse. Sono in vena di frasi massime quindi passatemela. Devo presentarvi MUIA_CycleChain, 1, e sono quindi giustificato. Chi ha usato windows almeno una volta nella sua vita sa che per passare da un oggetto all’altro basta premere il tasto TAB. Se questa cosa non la sapete è perchè non avete manco acceso mai il vostro computer. Bene, sotto amiga per ottenere lo stesso effetto si batte il tasto INVIO. La sequenza di tutti gli oggetti cui si passa dall’uno all’altro tramite INVIO (o tab sotto amiga), si chiama Cycle Chain, cioè catena ciclica. Questo perchè arrivati all’ultimo oggetto della catena (tab tab tab oppure invio invio invio, ricordo che dovete aver acceso il computer) si ricomincia dal primo oggetto. Per far si che un oggetto entri nella cycle chain bisogna settare l’attributo MUIA_CycleChain a 1. Questo da manuale: da mia esperienza pratica deve essere un qualsiasi intero positivo. Il numero che ci mettete indica la posizione nella catena. Ovviamente 1 viene prima di 2 che viene prima di 3 e così via. Provare per credere. Quindi se il tasto X lo volete al terzo posto della cycle chain scriverete: MUIA_CycleChain, 3, Purchè vi ricordiate di accendere il computer…

rebulator2

Rebulator è alla 0.3!!! Oggi l’ho compilato sotto morphos Apro la shell e digito: “gcc rebulator3.c -noixemul -o rebulator3″ Immediatamente gcc mi segnala dei problemi di dichiarazione variabili. Da bravo caprone io metto insieme dichiarazioni e definizioni e gcc sotto aros il problema non me lo crea. Ho modificato allora il codice e ho messo prima tutte le dichiarazioni e poi a seguire tutte le inizializzazioni. Problema risolto. Diciamo ora che è un pò di tempo (almeno una settimana che non scrivo). Ho risolto un pò di problemi. Nell’ordine: 1) Ora rebulator ha un layout liquido. Cioè lo ingrandisci o rimpicciolisci quanto ti pare ma è sempre visibile. Uno degli attributi dell’oggetto window (finestra) è MUIA_Window_SizeGadget, che, come dice il nome, controlla la presenza o meno del gadget di ridimensionamento. Volevo fare la cosa figa e avevo scritto, in seno alla definizione della mia finestra la seguente riga: MUIA_Window_SizeGadget, FALSE, Come prima cosa notiamo che il secondo elemento di muia etc è un bool (cioè un tipo di dato che assume i valori FALSE E TRUE, falso e vero). Dicendo FALSE ho detto che non lo voglio. Di default (cioè di base) il gadget di ridimensionamento è settato a TRUE. Cavemann di aros-exec mi fece notare la cosa dicendo: se metti un workbench in alta risoluzione che fai? Ti cechi? Ecco fatto. Cancellata la riga e riabbiamo il rebulator ridimensionabile!!! Voglio in futuro prevedere la possibilità di aumentare la dimensione del font man mano che aumento le dimensioni della finestra. Se no cavemann si ceca lo stesso.:) 2) Ho introdotto come potete vedere delle cornicette intorno agli oggetti principali! In inglese (e mui non fa eccezione) si chiamano FRAME. L’oggetto frame è come tutti gli altri componenti dell’interfaccia MUI un gadget. Tradott da boopsi in oggetto. Quindi ha i suoi bravi attributi e i suoi bravi metodi. Quelli che ci interessano di più quali sono? Vado a vedere che non mi ricordo:D:D Partiamo con un pochetto di teoria dicendo che come molti delle classi di MUI anche la classe FRAME deriva dalla classe AREA ereditandone quindi attributi e metodi. Per la stessa e identica ragione MUI sa come definire un FRAME praticamente per ogni oggetto: basta dirgli il tipo di oggetto al quale deve “conformarsi”. Prendiamo il seguente pezzo di codice Child, VGroup,//FRAME VISORE MUIA_Frame, MUIV_Frame_Group, Child, primo= TextObject, …. End, Child, secondo= TextObject, …. End, End, Con questo pezzo di codice creo un VGROUP cioè un gruppo verticale (cioè uno sotto l’altro). Nello specifico gli oggetti saranno due: primo e secondo, due bravi textobject con le loro proprietà (…). Come vedete la seconda riga dice: MUIA_Frame, MUIV_Frame_Group, Questa è la chiave. La coppia ordinata MUIA_Frame, MUIV_Frame_Group dice: ho bisogno di un frame che faccia da “contenitore” a un gruppo. Questi due semplici tag ci permettono di ottenere un frame che avvolga totalmente un gruppo. Dei frame devo dire che inizialmente mi confondeva una cosa: MUI è molto visuale. E si scrivono i tag necessari nel posto (fisico direi) dove ce n’è bisogno. Per cui tendevo a voler mettere i tag del frame all’esterno del gruppo visto che un frame circonda il gruppo cioè ne è all’esterno. Ma se ci ragioniamo la dicitura: Child, VGroup, … End, Alla fine è un insieme di macro (“abbreviazioni”) di una serie di tag che servono a creare un gruppo di oggetti. Nello specifico VGroup è l’abbreviazione di MUI_NewObject(MUIC_Group, dove la virgola finale sta a indicare che MUI si aspetta altri tag che caratterizzino il nostro gruppo (vale per qualsiasi oggetto non solo i gruppi). Quindi è più che logico che io il frame lo crei dopo l’apertura del gruppo! Tanto per dirne un’altra l’HGroup (che è il gruppo orizzontale cioè oggetti in sequenza sulla stessa riga) è l’abbreviazione di: MUI_NewObject(MUIC_Group,MUIA_Group_Horiz,TRUE Cioè un gruppo normalissimo, con in più l’attributo MUIA_Group_Horiz settato a TRUE cioè VERO. Le abbreviazioni in mui sono spesso presenti e “spesso” ci semplificano la vita. Un’altra caratteristica utile dei frame di gruppo (parliamo sempre della cornice che circonda un gruppo di oggetti) è la possibilità di avere un titolo! Si, proprio un titolo: Hmmmm… immaginiamoci un programma di contabilità (che fantasia!!)! Una finestra ci chiede di inserire i vari dati di un cliente. Potremmo distinguere le varie tipologie di dati separando i gadget in vari frame e nominando i vari frame con dei titoli: “dati anagrafici”, “ordini”, “bilancio” e così via. Quella del titolo del frame è una piccolezza ma molto utile per l’ordine a video. Come impostare il titolo di un frame? Semplicemente, al solito avremo una coppia ordinata attributo-valore: MUIA_Frame_Title, “si si si un bel titolo qui”, Come si vede i frame sono una figata immensa. P.s. se andate a vedere il sorgente di rebulator si possono inserire più frame innestati l’un dentro l’altro. 3) Ora i tasti di rebulator non sono attivabili solo da mouse. Come spiegavo più giù sono dovuto passare dai simplebutton() ai TextObject. Entriamo un pò di più nel dettaglio. Più volte ho parlato di macro, define, sostituzioni e abbreviazioni. Per chi programma un pò in c si sa che è usanza di andare a scrivere il programma polpacchioso in uno o più file sorgente (source file) aventi estensione .c (cpp per gli adoratori di stroustrup ma sono dei pervertiti quindi lasciamoli stare :D) e “l’anima leggera” le dichiarazioni di costanti, funzioni e direttive varie all’interno di uno o più file intestazione (header file) aventi estensione .h (pare che gli adoratori di stroustrup non abbiano trovato di meglio qui). E’nel nostro file h che spesso si trovano appunto le macro. Senza riscoprire la ruota in c esiste un’istruzione detta di “preprocessore” a nome “define”, meglio ancora #define. Uno dei vari usi di #define (non l’uso) è quello di sostituire un “nome” a una serie di istruzioni o valori. Esempioooooooooooo: #define PIGRECO 3.14 #define moltiplicazione(x) x*x #define SimpleButton(label) MUI_MakeObject(MUIO_Button,label) -Nel primo caso sto istruendo il compilatore con il fatto che ogni qualvolta lui trovi scritto PIGRECO lui sostituisca il valore 3.14, così che se scrivo una cosa tipo x+PIGRECO il compilatore sa che invece deve operare come x+3.14; Questo primo caso è quello cosiddetto della costante simbolica perchè abbiamo creato una costante (3.14) dandogli un nome (PIGRECO). PS non provate ad assegnare valori che il compilatore vi picchia. E’una costante non una variabile. - Nel secondo e terzo caso invece andiamo a sostituire a un nome (o a un’espressione) un’ulteriore espressione. Ecco cos’è una macro! MACRO(CIOE’GROSSA, CICCIOTTA) OPERAZIONE! In pratica scrivo Simplebutton(“ciao”) e lui crea un casino creandomi un oggetto MUI basato su di un oggetto “prefabbricato” (arriveremo pure a questo. ci sono malati mentali che creano le macro di macro, credetemi… ma per ora non distraiamoci) MUIO_Button con titolo label. Molto più semplice no? Provare per credere. Idem per l’operazione. In pratica con define quindi vado a creare delle vere e proprie funzioni o comunque a semplificare la vita con le costanti simboliche di chi programma. Ma tutto questo ha un prezzo… Il simplebutton è semplicissimo da usare: lo scopo delle macro in mui è proprio quello. Mascherare la complessità. Ma contemporaneamente non si ha controllo completo su quello che si fa. Ho dovuto abbandonare simplebutton e alcune (non tutte. non sono masochista) macro nel momento in cui ho capito che con simplebutton non avrei potuto: 1) modificare a piacimento le dimensioni dei pulsanti. 2) modificare a piacimento (di conseguenza) il layout di rebulator 3) non poter usare i comandi da tastiera per i pulsanti (ad esempio usare il tastierino numerico per eseguire i calcoli della calcolatrice). Sono dovuto quindi tornare agli oggetti (non inteso come programmazione) ma inteso come oggetti fisici, come gadget con tutte le loro brave funzioni. Senza sconti. Chi ha scaricato o ha visto una delle ultime versioni di rebulator ha notato un pò di cose rispetto alle versioni precedenti (con tutti i pulsanti uguali): - i pulsanti + e = sono alti il doppio rispetto agli altri; - i pulsanti di gestione della memoria sono molto più schiacciati e larghi; - i pulsanti della terza fila sono molto più stretti rispetto agli altri; - se si prova a modificare le dimensioni della finestra di rebulator vengono mantenute le proporzioni del layout base. Ora noi sappiamo che per programmare l’aspetto di MUI bisogna intervenire sui tag (cioè sugli attributi) dei singoli elementi che compongono l’interfaccia. E gli oggetti con macro di loro sono già dei pacchetti “intoccabili”. Sono un tutto incluso invariabile. Ora noi sappiamo (non è vero lo sto dicendo ora) che gli oggetti pulsante altro non sono che degli oggetti “text” con delle caratteristiche particolari. Ho mentito prima. Devo parlare di programmazione orientata agli oggetti (oop). Ma giuro che mi mantengo a un livello teorico. Odio la programmazione orientata agli oggetti. Allora… L’elemento base dell’oop è la CLASSE. La classe in oop è la rappresentazione, il modello, l’astrazione di un concetto. Esempio: qui ho il mio gatto. Voglio astrarre il concetto di gatto e quindi creare “la gattità”, cioè l’insieme di tutte quelle proprietà ed attività che rendono tale un gatto. Nel momento in cui avrò fatto questo avrò creato “la classe gatto”. Ora il mio gatto a parte dormire perchè oggi piove, di solito mangia e spesso miagola. E queste sono le attività (in oop quelli bravi le chiamano “metodi”). Le caratteristiche, le proprietà invece quali sono?? 1) le vibrisse 2) le orecchie a punta 3) la coda flessuosa 4) le zampe con le unghie retrattili. Ecco, molto approssimativamente questo è un gatto. “la classe gatto” composto quindi di una serie di attributi (le proprietà) e i metodi (le funzioni). E gli oggetti? L’oggetto è un’istanziazione della classe. Che vorrà dire? Semplicemente: la classe gatto riunisce in sè le caratteristiche di cui prima, ma quel gatto particolare, quello con il pelo a strisce che non mangia cibo secco e che rompe se mi metto sul letto senza di lui e che risponde al nome di Pachino, ecco, quello è un oggetto. “Un particolare gatto” quello è l’oggetto della classe gatto. Ma, se riflettiamo, anche il cane mangia e dorme, solo che non miagola: abbaia. La classe cane allora ha qualcosa di simile alla classe gatto. La canità è affine alla gattità. E infatti entrambi sono animali (un’altra classe!!!). La classe animale ha allora una serie di caratteristiche comuni a tutte le classi che da essa derivano quali mangiare e dormire, poi qualcuno vola, qualcuno striscia e qualcuno corre. Se ci riflettiamo quest’attività di classificazione è qualcosa a noi di naturale: è ciò che facciamo in ogni branca di lavoro o scibile. Ritornando alla oop: dicevamo che esiste una classe animale che ha in sè delle proprietà e dei metodi base (mangiare, dormire, massa, volume). Questi proprietà e metodi base vengono “ereditati” dalle classi “derivate” e talvolta vengono “adattate” alla singola classe. E’chiaramente differente il “mangiare” del gatto rispetto a una sanguisuga. Ma entrambi mangiano. Sintetizzando possiamo dire allora che in oops: Da una classe base (superclasse) possiamo derivare una o più classi (derivate) che conservano le proprietà e i metodi della classe base (ereditarietà). Ritorniamo a MUI così capiamo pure un pò di cose. Prima di tutto vi invito a visionare l’insieme di tutte le classi di MUI C’è una lista di tante belle cosette che significano poco. Al massimo potrebbero essere le fermate della metro o gli svincoli della tangenziale. Scherzi a parte, iniziando a leggere dall’alto verso il basso avremo il primo elemento “rootclass” che è la “Classe radice” superclasse delle superclassi dell’universo MUI. Se ho capito bene non è una vera classe ma uno stratagemma che stuntz (il creatore di MUI) usa per collegarsi a BOOPSI. La prima vera superclasse è NOTIFY dalla quale discendono praticamente tutte le altre (se vedete il grafico semaphore è a parte). Dire che tutte (o quasi) discendono da notify significa che tutte le classi derivate da notify ne erediteranno metodi e proprietà. Facciamo un bel click su notify. Si apre la pagina della guida relativa a questa classe: si inizia con una breve descrizione della stessa e poi un insieme di attributi (iniziano sempre con MUIA) e metodi (cioè funzioni proprie di quella classe e iniziano sempre con MUIM). Questi metodi e attributi, magia dell’ereditarietà saranno fruibili anche da tutte le classi derivate! Ma cosa centra tutto questo col nostro bravo pulsante? Ecco qua! Child, button_memr=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, MUIA_Text_HiChar, ‘r’, MUIA_ControlChar, ‘r’, MUIA_Text_Contents, “MR”, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 1, MUIA_Text_SetVMax, FALSE, MUIA_InnerBottom, 0, MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Ecco cosa centra! Abbiamo detto che un oggetto pulsante è in realtà un oggetto della classe text con alcune particolarità. Vi invito ad aprire qui E’la pagina di documentazione della classe text. Se ci fate caso i tre quarti degli attributi che ho scritto sopra non ci sono nella classe text! Alla classe text degli attributi che ho scritto su appartengono solo: MUIA_Text_HiChar, MUIA_ControlChar, MUIA_Text_Contents, MUIA_Text_PreParse, MUIA_Text_SetVMax. E il resto? Da dove sono usciti? Semplice! Guardando un pò la documentazione in linea di MUI scopriremo che gli altri attributi appartengono alle superclassi dalle quali la classe text è stata derivata! Quindi volendo sempre rimanere a un livello terra terra, io posso usare tutti gli attributi (e i metodi) che sono stati scritti per la mia classe e per quelle dalle quali questa deriva! Volendo chiamare le cose col loro nome: MUIA_Font, CLASSE AREA MUIA_Text_HiChar, CLASSE TEXT MUIA_ControlChar, CLASSE TEXT MUIA_Text_Contents, CLASSE TEXT MUIA_Text_PreParse, CLASSE TEXT MUIA_InputMode, CLASSE AREA MUIA_Background, CLASSE AREA MUIA_CycleChain, CLASSE AREA MUIA_Text_SetVMax, CLASSE TEXT MUIA_InnerBottom, CLASSE AREA MUIA_InnerTop, CLASSE AREA //MUIA_FixHeightTxt, CLASSE AREA //MUIA_FixWidth, CLASSE AREA //MUIA_VertWeight, CLASSE AREA Come vedete abbiamo quindi usato nel nostro pulsante non solo gli attributi della classe text ma anche quelli della classe area che è uno dei genitori di text. Questo in MUI vale sempre. Potete usare e sperimentare gli attributi delle superclassi nelle derivate e vedere che succede! Qualcuno giustamente avrà notato una cosa: ma TextObject e ButtonFrame ma da dove escono? Non sono descritti da nessuna parte. Da dove li prendo? Poi questo che scrive ci fa due scatole lui che tutto deve avere il prefisso MUIA, MUIV, MUIC e questi non ce li hanno? Risposta: manco simplebutton aveva il prefisso MUI. Si capisce allora (a intuito e a mazzo) che ButtonFrame e TextObject, ancora una volta sono il frutto di due #define… Ma ste cacchio di define dove le trovo tutte quante? Prima rispondo e poi mi lamento: nel file mui.h contenuto in questo archivio Ora mi posso lamentare: io non sono un buon programmatore, e se scrivo questa guida è perchè così butto giù due appunti che forse sono più utili a me che a chi legge, tanto sono caotici. Ma se c’è una cosa per la quale ho sofferto, soffro e peno, se ancora scrivo questa guida è perchè in Amiga ormai manca totalmente il concetto di “documentazione”. Qualcuno si incavola? E’così. Per capire qualcosa di MUI ho buttato letteralmente il sangue quando è di una banalità assurda. Le uniche cose esistenti su questa terra sono l’ottima guida di shinkuro e l’egualmente ottimo sito di guru-meditation in francese. Per il resto è un buttamento di sangue. E se io non mi ricordavo che i programmatori c vanno a leggersi i file h “per documentarsi” io manco ci arrivavo a quel poco ove sono arrivato. E se io ho un pò di teoria e poca pratica immagino chi difetta anche di quel poco e cerca un testo, un libro che lo introduca a tutto ciò. Orbene se vi andate a leggere il file mui.h troveremo che #define ButtonFrame MUIA_Frame, MUIV_Frame_Button cioè buttonframe è una macro per costruire un frame(MUIA_Frame) di tipo MUIV_Frame_Button (MUIV sta per MUI Value). Stesso vale per TextObject: #define TextObject MUI_NewObject(MUIC_Text Per ora non ci soffermiamo molto sulle istruzioni come newobject, sappiate però che è un metodo che, come dice il nome, serve a creare un oggetto (NewObject) di un determinato tipo (nel nostro caso derivante dalla classe MUIC_Text MUIC sta per MUI Class cioè classe mui). Andiamo invece ad analizzare nel dettaglio il codice del nostro pulsante: Child, button_memr=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, MUIA_Text_HiChar, ‘r’, MUIA_ControlChar, ‘r’, MUIA_Text_Contents, “MR”, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 1, MUIA_Text_SetVMax, FALSE, MUIA_InnerBottom, 0, MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Tanto per iniziare notiamo di come, al solito, iniziamo e chiudiamo tutto con i tag Child ed End che, rispettivamente, aprono e chiudono un oggetto “figlio” del layout di MUI. Poi, abbiamo: button_memr=TextObject, in pratica dichiariamo un TextObject, il cui indirizzo è memorizzato in button_memr. button_memr è un puntatore a object che ho dichiarato precedentemente nel codice. Quando abbiamo parlato delle variabili abbiamo visto di come non sia strettamente necessario definire una variabile per un gadget ma se lo faccio, poi, posso usarlo per l’elaborazione! A seguire abbiamo ButtonFrame che, come abbiamo visto, è quella macro che circonda il nostro textobject con una bella cornicetta da “pulsante”. Se andiamo a vedere in mui.h vedremo che ci sono diversi tipi di frame predefiniti. Li elenco brevemente: #define NoFrame MUIA_Frame, MUIV_Frame_None #define ButtonFrame MUIA_Frame, MUIV_Frame_Button #define ImageButtonFrame MUIA_Frame, MUIV_Frame_ImageButton #define TextFrame MUIA_Frame, MUIV_Frame_Text #define StringFrame MUIA_Frame, MUIV_Frame_String #define ReadListFrame MUIA_Frame, MUIV_Frame_ReadList #define InputListFrame MUIA_Frame, MUIV_Frame_InputList #define PropFrame MUIA_Frame, MUIV_Frame_Prop #define SliderFrame MUIA_Frame, MUIV_Frame_Slider #define GaugeFrame MUIA_Frame, MUIV_Frame_Gauge #define VirtualFrame MUIA_Frame, MUIV_Frame_Virtual #define GroupFrame MUIA_Frame, MUIV_Frame_Group #define GroupFrameT(s) MUIA_Frame, MUIV_Frame_Group, MUIA_FrameTitle, s, MUIA_Background, MUII_GroupBack Come vediamo ce n’è per tutti i gusti e sono anche abbastanza intuitivi. Giusto a ulteriore bonus mui.h contiene anche diversi esempi di codice. Io me lo sono stampato e ogni tanto, quando ho qualche dubbio, me lo spulcio. A seguire c’è un attributo utilissimo che è MUIA_Font: serve a impostare, come si intuisce, il font per quel determinato oggetto (dico oggetto e non pulsante in virtù delle considerazioni fatte sull’ereditarietà e quindi tale attributo lo useremo anche per altri oggetti così che ogni oggetto di una finestra MUI potrebbe avere il suo font diverso!Attualmente è impostato a MUIV_Font_Button. Che è il font specifico per i pulsanti. Ciò non toglie che esistono diversi valori che possono essere usati per MUIA_Font e li troviamo bel belli nella documentazione sul sito di MUI. Ve li elenco. MUIV_Font_Inherit MUIV_Font_Normal MUIV_Font_List MUIV_Font_Tiny MUIV_Font_Fixed MUIV_Font_Title MUIV_Font_Big MUIV_Font_Button MUIV_Font_Slider MUIV_Font_Gauge Dico la verità ho usato solo il tiny, il normal e il button. Gli altri poi li andrò a usare.Provare, provare, provare. MUIA_TExt_HiChar, prendendo ad esempio il pulsante che, sappiamo, è composto di un’area cliccabile col mouse e una “label” cioè una scritta più o meno intuitiva che ci fa capire a cosa serva quel pulsante (ad esempio OK piuttosto che ANNULLA o SALVA) e l’HiChar è quel carattere, tra quelli della label, che apparirà sottolineato. Questo è solo un effetto grafico e non da effetti reali. Cmq, nel nostro caso la riga MUIA_Text_HiChar, ‘r’, fa si che il carattere r appaia sottolineato sul pulsante in questione. Ovviamente ci aspetteremmo però che non sia solo un effetto grafico e che premendo r si metta in funzione quel pulsante. Questo è dato da MUIA_ControlChar. Questo attributo MUI non ha effetti grafici ma se scrivo la riga che ho scritto: MUIA_ControlChar, ‘r’, allora premendo il tasto r il pulsante in questione produrrà i suoi effetti. MUIA_Text_Contents è invece il tag che definisce la label (l’etichetta) di un pulsante. Può essere una stringa delimitata da virgolette oppure un vettore (puntatore) a char nel caso in cui vogliamo una variabile da elaborare.Ricordo qualche tempo fa di aver avuto dei problemi con un oggetto stringa risolti con dei casting (verso varchar??) o iptr? e chi si ricorda:D Appena riprendo i listati correggo. E’ possibile formattare le stringhe con le sequenze di escape. al solito rimando alla documentazione di mui ed in particolare al seguente link: http://www.sasg.com/mui/autodocs/MUI_Te … t_Contents E’arrivato il turno di MUIA_Text_PreParse. Serve a dare una formattazione alla label (centrata, sottolineata etc) senza modificare la stringa originale. Nel nostro esempio abbiamo: MUIA_Text_PreParse, “33c”, 33 è una sequenza di escape (come si dice tra quelli che parlano stretto) ed è un codice che viene applicato in fase di lettura della stringa e sua formattazione. la “c” sta per “centra”, cioè: la label del pulsante deve essere centrata. Se aggiungessi un b e quindi abbiamo 33c33b a quel punto ho due codici: il c, come già detto, per la centratura e la b per il grassetto. MUIA_InputMode, MUIV_InputMode_RelVerify, Arriviamo adesso alle cose interessanti! Non che le altre cose non lo siano ma queste lo sono particolarmente. Precedentemente avevamo detto che in MUI un oggetto pulsante vero e proprio non esiste bensì esso altro non è che un oggetto che un oggetto derivato dalla classe AREA. Non l’avevamo detto? L’ho detto ora:D Cosa rende un pulsante tale? Una bella area (manco a farlo apposta) che se la clicco (di solito col pulsante sinistro del mouse) succede un qualcosa. MUI utilizza due attributi booleani (i primi due) e un attributo intero (con funzione di temporizzatore) per la gestione del pulsante sinistro del mouse: 1) MUIA_Selected: è quell’attributo dell’oggetto che ha a che fare con la sua selezione. 2) MUIA_Pressed: è quell’attributo il cui valore ha a che fare con la pressione (o meno) del pulsante sinistro del mouse sull’oggetto 3) MUIA_Timer: è un temporizzatore che memorizza da quanto tempo il pulsante sinistro del mouse è premuto su un gadget bottone. Ora, la classe area ha nell’attributo MUIA_InputMode un importante strumento per definire il comportamento dei gadget BOTTONI et similia (non i bottoni del mouse proprio i gadget delle finestre. Tra buttoni, pulsanti e oggetti ci si confonde:P) In pratica gestisce, come suggerisce il nome, il comportamento di un oggetto di fronte all’input e (nello specifico) rispetto alla pressione del pulsante sinistro del mouse. Entrando più nel dettaglio MUIA_InputMode ha quattro possibili valori: MUIV_InputMode_None, MUIV_InputMode_Relverify, MUIV_InputMode_Immediate e MUIV_InputMode_Toggle. Ma che relazione hanno i valori di MUIA_InputMode e gli attributi sopra visti? Semplicemente, scegliendo uno dei valori di MUIA_InputMode, sceglieremo anche come il nostro oggetto si regolerà rispetto agli attributi MUIA_Selected, MUIA_Pressed e MUIA_Timer. Vediamo come: 1)MUIV_InputMode_None: come dice il none l’oggetto in questione non risponde agli input e quindi se ne frega alla grande di MUIA_Selected, MUIA_Pressed e MUIA_Timer 2) MUIV_InputMode_RelVerify: è il valore di default per i bottoni. - MUIA_Selected (ricordiamo che è un bool): vero quando il pulsante sx viene premuto su esso falso quando il pulsante sx viene rilasciato falso quando il gadget è selezionato ma il mouse esce dall’area dell’oggetto vero quando il mouse rientra nell’area dell’oggetto. In pratica definendo MUIV_InputMode_RelVerify come valore di MUIA_InputMode avremo scelto di associare all’oggetto in questione questi comportamenti. - MUIA_Pressed vero quando il pulsante sx viene premuto su esso (come MUIA_Selected: ovviamente se premo il pulsante sinistro lo sto anche selezionando) falso quando lascio il pulsante sx. Qui si aprono due strade: –se il mouse è ancora sull’oggetto si scatena una notifica. –se il mouse non è sull’oggetto all’atto del rilascio non si scatena una notifica. Perchè si scatena una notifica quando lascio il pulsante sinistro del mouse se il puntatore è ancora sull’oggetto? Beh, fateci caso. Quando premete il pulsante del mouse su un bottone non succede un bel niente. E’quando lo rilasciate che succede qualcosa. PRovare per credere!!:))) - MUIA_Timer: attributo long, come dicevamo si tratta di un temporizzatore che entra in funzione dopo che un bottone RelVerify è stato premuto e tiene conto del tempo di pressione del pulsante sx. Non l’ho ancora usato e quindi è da approfondire. 3)MUIV_InputMode_Immediate: è il valore che ha a che fare con i radio button e altri oggetti che, come dice il nome, hanno una reazione immediata alla pressione del mouse. Proprio a causa di questo suo modo di essere l’attributo MUIA_PRessed non è definito MUIA_Selected: si scatena non appena il pulsante sx viene premuto sull’oggetto 4)MUIV_InputMode_Toggle: è il valore degli oggetti come i check (toggle tradotto letteralmente significa togli e se volete ciò che si fa con i check è proprio togliere e metter quella benedetta x nella casellina) Anche qui MUIA_Pressed non ha senso. MUIA_Selected invece diventa falso quando si preme il pulsante sx del mouse (al contrario di MUIV_Input_Immediate). Ricordo sempre che con get e set c’è la possibilità di leggere e scrivere questi valori negli oggetti così da “forzare” la mano laddove necessario o reperire gli stessi! Ritorniamo alle decorazioni: Continuando nella descrizione del nostro pulsante, incontriamo la coppia attributo-valore MUIA_Background, MUII_ButtonBack, Come possiamo immaginare MUIA_Background è quell’attributo MUI che gestisce lo sfondo (background) di un oggetto. Lo sfondo di un oggetto è normalmente un’immagine e il nostro sfondo non fa eccezzione: il valore infatti è MUII_ButtonBack. Ricordiamo che MUII sta per MUI Image, cioè Immagine Mui. Valore che in questo caso è guarda caso ButtonBack, cioè sfondo per i bottoni. MUIA_Background assume diversi valori tutti da provare e vi rimando alla documentazione MUI a riguardo. Carina come cosa è quella di provare varie immagini per vari tipi di oggetto: siamo nell’ambito delle decorazioni e allora perchè non provare a cambiare? Se la vocina nel cervello vi dice: “per non confondere le cose!” Non ascoltatela! Provate provate provate. E poi fatemi sapere. Mi incuriosisce quello shine back.:p Alzi la mano chi ritiene il mouse senza tastiera utile. Il mouse senza tastiera è meno utile della tastiera senza mouse. Sono in vena di frasi massime quindi passatemela. Devo presentarvi MUIA_CycleChain, 1, e sono quindi giustificato. Chi ha usato windows almeno una volta nella sua vita sa che per passare da un oggetto all’altro basta premere il tasto TAB. Se questa cosa non la sapete è perchè non avete manco acceso mai il vostro computer. Bene, sotto amiga per ottenere lo stesso effetto si batte il tasto INVIO. La sequenza di tutti gli oggetti cui si passa dall’uno all’altro tramite INVIO (o tab sotto amiga), si chiama Cycle Chain, cioè catena ciclica. Questo perchè arrivati all’ultimo oggetto della catena (tab tab tab oppure invio invio invio, ricordo che dovete aver acceso il computer) si ricomincia dal primo oggetto. Per far si che un oggetto entri nella cycle chain bisogna settare l’attributo MUIA_CycleChain a 1. Questo da manuale: da mia esperienza pratica deve essere un qualsiasi intero positivo. Il numero che ci mettete indica la posizione nella catena. Ovviamente 1 viene prima di 2 che viene prima di 3 e così via. Provare per credere. Quindi se il tasto X lo volete al terzo posto della cycle chain scriverete: MUIA_CycleChain, 3, Purchè vi ricordiate di accendere il computer… Gli ultimi 6 elementi riguardano tutti la “spaziatura” e il layout dell’oggetto bottone ch rebulator implemente. Gli ultimi 3 in particolare sono commentati visto che alla fine non li ho usati. La mia esigenza era quella di creare per rebulator dei pulsanti che non avessero necessariamente tutti la stessa dimensione o lo stesso aspetto. MUI di suo tende a dividere lo spazio della finestra in oggetti di egual dimensione o comunque ad accomodare in maniera armonica gli oggetti su di essa. Non sempre però è ciò che si vuole: sulle calcolatrici il pulsante + o il pulsante = di solito sono più grandi degli altri così come il modello di rebulator, che è una calcolatrice cinese da tre soldi, ha i pulsanti della gestione memoria più piccoli rispetto agli altri. Come ottenere quindi pulsanti di dimensioni diverse pur rimanendo nell’ambito di un layout omogeneo? Le strade sono varie: creare gruppi ad hoc, così come giocare sugli attributi. Quelli presenti nelle righe che vedremo permettono un bel pò di personalizzazioni in merito: 1) MUIA_Text_SetVMax (BOOLEANO) Derivato dalla classe TEXT, è un attributo che stabilisce in un oggetto se l’altezza massima dello stesso sia limitata all’altezza del testo in essa contenuto. In pratica l’oggetto non potrebbe mai espandersi verticalmente se questo attributo avesse come valore TRUE In rebulator è settato a FALSE perchè Rebulator ha un layout liquido: se si allarga la finestra anche i suoi pulsanti si devono allargare o allungare di conseguenza. Una delle prossime cose che studierò sarà come ingrandire i font in tempo reale. 2) MUIA_InnerBottom Definisce, in pixel, lo spazio che il sistema deve lasciare dal “bottom” cioè dalla base del testo alla cornice. Settandolo a 0 gli ho detto che non voglio pixel tra la base del testo e la cornice. Mi serviva per i tasti memoria per “schiacciarli” in altezza il più possibile 3) MUIA_InnerTop Idem come inner bottom. Solo che lo spazio stavolta è quello riservato sopra il testo. Settando a 0 questo attributo dico a MUI che non voglio spazio di pixel tra il testo e la cornice. 4) MUIA_FixHeightTxt E’commentato dunque non è attivo in rebulator. E’ un attributo che dice a MUI che l’altezza di quel determinato oggetto (height) debba essere fissata (fix) all’altezza del testo che gli si passa come valore (in questo caso MR). Utile per limitare l’altezza. Credo faccia a cazzotti con MUIA_Text_SetVMax, FALSE. 5) MUIA_FixWidth Anch’esso commentato. Attributo che riceve come valore il numero di pixel il cui valore rappresenta la larghezza dell’oggetto. Utile per delimitare la larghezza 6) MUIA_VertWeight Un argomento particolarmente interessante e importante di MUI sono i “pesi”. Dicevo che MUI cerca di organizzare il layout in maniera armonica. Come dice il termine, dando quindi a tutti gli oggetti un “peso” uguale o quantomeno quel giusto tot. Il peso di un oggetto è il meccanismo invece che MUI usa per alterare questo equilibrio. Il peso di un oggetto, inteso come spazio (verticale o orizzontale o entrambi) che l’oggetto deve occupare rispetto a ciò che normalmente gli sarebbe concesso in funzione del numero e tipo di oggetti presenti nel suo gruppo, è definito in “percentuale”. Se un oggetto deve occupare più del suo normale spazio avrà quindi un valore di attributo superiore a 100. Viceversa se ne deve occupare di meno sarà inferiore a 100. Un valore pari a 0 (laddove non produca dei bei crash di sistema:p) indica a MUI che l’oggetto deve occupare “sempre” il minimo dello spazio consentito. Ora gli attributi che si occupano di gestire il peso di un oggetto MUI sono 3: - MUiA_Weight: gestisce il peso dell’oggetto sia in verticale che in orizzontale. Esempio: MUIA_Weight, 300, significa che l’oggetto (in verticale e in orizzontale) occuperà il 300% del normale spazio. - MUIA_VertWeight: come prima ma regola solo il “peso” verticale (quindi lo spazio in altezza) dell’oggetto. - MUIA_HorizWeight: idem. Solo che abbiamo a che fare con il peso orizzontale. Perchè avevo messo tutto a 0? Semplicemente perchè volevo che i pulsanti di gestione memoria non fossero “armonici” ma fossero schiacciati. Ed è ciò che ho ottenuto:P Veniamo ancora al “peso”. Altra problematica che ho dovuto affrontare è stata quella del mantenimento delle proporzioni degli oggetti all’atto del ridimensionamento della finestra: avendo rebulator un “layout liquido” significa che se ridimensiono la finestra si devono ridimensionare tutti i gadget ma, e qui sorge il problema, quando ridimensionavo la finestra, le proporzioni tra i gadget ne uscivano stravolte. Cosa ho fatto? Semplice, ho giocato appunto con i pesi. Ritorniamo sempre all’esempio dei tasti quelli di memoria, subito dopo il visore e prima dei tasti numerici. Sono schiacciati e voglio che rimangano tali anche se ridimensiono tutto. Bene. Ho detto a MUI che il gruppo (un HGROUP cioè un gruppo orizzontale) dovesse avere un VertWeight, cioè un peso verticale pari a 20. Child, HGroup, MUIA_VertWeight, 20, MUIA_Frame, MUIV_Frame_Group, MUIA_Group_SameSize, TRUE, Child, button_memr=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, MUIA_Text_HiChar, ‘r’, MUIA_ControlChar, ‘r’, MUIA_Text_Contents, “MR”, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 1, MUIA_Text_SetVMax, FALSE, MUIA_InnerBottom, 0, MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Child, button_memc=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, MUIA_Text_HiChar, ‘c’, MUIA_ControlChar, ‘c’, MUIA_Text_Contents, “MC”, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 2, MUIA_Text_SetVMax, FALSE, MUIA_InnerBottom, 0, MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Child, button_memp=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, //MUIA_Text_HiChar, ‘p’, MUIA_ControlChar, ‘p’, MUIA_Text_Contents, “M+”, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 3, MUIA_Text_SetVMax, FALSE, MUIA_InnerBottom, 0, MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Child, button_memm=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, //MUIA_Text_HiChar, ‘m’, MUIA_ControlChar, ‘m’, MUIA_Text_Contents, “M-”, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 4, MUIA_Text_SetVMax, FALSE, MUIA_InnerBottom, 0, MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Child, button_canc=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, MUIA_Text_HiChar, ‘a’, MUIA_ControlChar, ‘a’, MUIA_Text_Contents, “CA”, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 5, MUIA_Text_SetVMax, FALSE, MUIA_InnerBottom, 0, MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Child, button_ce=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, MUIA_Text_HiChar, ‘e’, MUIA_ControlChar, ‘e’, MUIA_Text_Contents, “CE”, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 6, MUIA_Text_SetVMax, FALSE, MUIA_InnerBottom, 0, MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, End,//HGROUP Chi ha visto rebulator sa che la fila dei tasti memoria occupa il minimo spazio possibile a causa dell’uso degli attributi innertop, innerbottom e così via. Quindi di suo occupa “già” il minimo possibile. Quando allora metto 20 come valore del peso verticale, sapete che succede? Che di fatto, quando modificate la dimensione della finestra la variazione in dimensione del gruppo “memoria” è minimo! BINGO!! Capito l’importanza dei pesi? Non servono solo per la gestione di un layout statico, ma anche per la gestione di un layout “dinamico”. Per la stessa ragione il VGROUP (gruppo verticale) che contiene i numeri, ha un attributo HorizWeight pari a 300! Io voglio che il gruppo occupi il 300% dello spazio che dovrebbe occupare e lo ottengo. Non solo: quando ridimensiono la finestra quel “300″ fa si che il gruppo sia molto più sensibile alle variazioni!! Riporto di seguito il listato della 0.3 targato 6 giugno 2011. Piena di bug (non di layout quanto comportamentali) poi corretti nella successiva 0.4. Ci si rivede al prossimo post! /*TO COMPILE IT: UNDER AROS: gcc rebulator3.c -lmui -o rebulator3 UNDER MORPHOS: gcc rebulator3.c -noixemul -o rebulator3 */ /*thanks to mr. cavemann, guru-meditation tutorials and morphzone guys*/ #include /* MUI */ #include /* OpenLibrary, wait */ #include /* MUI_DisposeObject */ #include /* SIGBREAKF_CTRL_C */ #include /* SPRINTF e SSCANF */ #include #include /* sprintf,sscanf and so on*/ #include /* pow, log, sin, cos */ /*to enter in debug mode and show some verbose msgs on screen*/ #define DEEJBUG 100 /*there are ID for signals*/ #define ID_MINUS 1 #define ID_PLUS 2 #define ID_MUL 3 #define ID_DIV 4 #define ID_ONE 5 #define ID_TWO 6 #define ID_THREE 7 #define ID_FOUR 8 #define ID_FIVE 9 #define ID_SIX 10 #define ID_SEVEN 11 #define ID_EIGHT 12 #define ID_NINE 13 #define ID_ZERO 14 #define ID_CANC 15 #define ID_ENTER 16 #define ID_POINT 17 #define ID_MEMP 18 #define ID_MEMM 19 #define ID_MEMR 20 #define ID_MEMC 21 #define ID_MINPL 22 #define ID_SQRT 23 #define ID_PERC 24 #define ID_INV 25 #define ID_CE 26 #define ID_DZERO 27 #define ID_XN 28 #define ID_LOGX 29 #define ID_SINX 30 #define ID_COSX 31 #define MEN_ABOUT 32 /*THE STATES REBULATOR HAS*/ typedef enum STATO {NORMAL, PLUS, MINUS, MULTIPLY, DIV, ERROR, STANDBY, PERC, INVERSE, SQRT, SINX, COSX, LOGX, XN, CE, CANC, ENTER, POINT, MEMR, MEMC, MEMM, MEMP, MINPL } statt; /*USED TO TRACK LAST PRESSED KEY*/ typedef enum TASTO {K_NONE, K_PLUS, K_MINUS, K_MULTIPLY, K_DIV, K_ERROR, K_PERC, K_INVERSE, K_SQRT, K_SINX, K_COSX, K_LOGX, K_XN, K_CE, K_CANC, K_ENTER, K_POINT, K_MEMR, K_MEMC, K_MEMM, K_MEMP, K_MINPL, K_ONE, K_TWO, K_THREE, K_FOUR, K_FIVE, K_SIX, K_SEVEN, K_EIGHT, K_NINE, K_ZERO, K_DZERO } tastt; statt stato; statt statoprec; tastt lastfkey; typedef enum BOOLY {T, F} boly; boly shake; boly giapuntoprimo; boly giapuntosecondo; boly bsecondo; typedef struct REGISTRI { boly giapuntoprimo; boly giapuntosecondo; boly bsecondo; float fprimo; float fsecondo; float frisultato; float fmemory; statt stato; statt statoprec; tastt lastfkey; char str_buf_primo[10]; char str_buf_secondo[10]; char str_buf_risultato[10]; char str_buf_memory[10]; } registri; registri storico[3]; /*FUNCTIONS*/ float strngfy(char *numero, char *carattere); int eseguioperazione(float first, float second,statt status, float *result); int resetta(float *first, float *second, float *result, char *str_first, char *str_second, char *str_result, boly *boolsecondo); int main(void) { /*IPTR strprimo, strsecondo;*/ char str_buf_primo[10], str_buf_secondo[10], str_buf_risultato[10], str_buf_memory[10]; /*char strrisultato[7];*/ Object *window1, *application1, *button_minus, *button_plus, *button_mul, *button_div, *primo, *secondo, *risultato, *button_nine, *button_eight, *button_seven, *button_six, *button_five, *button_four, *button_three, *button_two, *button_one, *button_zero, *button_canc, *button_enter, *button_point, *button_memp, *button_memm, *button_memr, *button_memc, *button_sqrt, *button_perc, *button_minplus, *button_inverse, *button_ce, *button_dzero, *button_sinx, *button_cosx, *button_logx, *button_xn, *infomenu, *protectmenu, *toolmenu, *aboutmenu, *quit, *keymenu, *xmenu, *ymenu; float fprimo; float fsecondo; float fmemory; float frisultato; float fbuf_memory; float fval_euro; giapuntoprimo=F; giapuntosecondo=F; bsecondo=F; fprimo=0; fsecondo=0; fmemory=0; frisultato=0; fbuf_memory=0; fval_euro=0; /*int buffer=0;*/ stato=NORMAL; statoprec=STANDBY; str_buf_primo[0]=”; str_buf_secondo[0]=”; str_buf_risultato[0]=”; str_buf_memory[0]=”; application1= ApplicationObject, MUIA_Application_Title, “Rebulator”, MUIA_Application_Version , “$VER: Mui Calculator 0.4″, MUIA_Application_Copyright , “Public Domain”, MUIA_Application_Author , “Rebraist”, MUIA_Application_Description , “First Calculator”, MUIA_Application_Menustrip, (IPTR)(MenustripObject, MUIA_Family_Child,(IPTR)(MenuObject, MUIA_Menu_Title, “Rebulator”, MUIA_Family_Child, (IPTR)(infomenu = MUI_MakeObject(MUIO_Menuitem,”About”, “A”, 0,0)), MUIA_Family_Child, (IPTR) (quit = MUI_MakeObject(MUIO_Menuitem, “Quit”, “Q”,0,0)), End), //(IPTR)MenuObject, MUIA_Family_Child, (IPTR) (MenuObject, MUIA_Menu_Title, “Tools”, MUIA_Family_Child, (IPTR) (MenuObject, MUIA_Menu_Title, “Keys”, MUIA_Family_Child, (IPTR)(keymenu = MUI_MakeObject(MUIO_Menuitem,”Standard”, CHECKIT|CHECKED,3,0)), MUIA_Family_Child, (IPTR)(xmenu = MUI_MakeObject(MUIO_Menuitem,”Extended”, CHECKIT,3,0)), End), End), End), /* MUIA_Application_Menustrip, (IPTR)(MenustripObject, MUIA_Family_Child,(IPTR)(MenuObject, MUIA_Menuitem_Title, “Rebulator”, MUIA_Family_Child, (IPTR)(infomenu = MUI_MakeObject(MUIO_Menuitem,”About”, “A”, 0,0)), MUIA_Family_Child, (IPTR) (quit = MUI_MakeObject(MUIO_Menuitem, “Quit”, “Q”,0,0)), //(IPTR)MenuObject, MUIA_Family_Child, (IPTR) (MenuObject, MUIA_Menu_Title, “Tools”, MUIA_Family_Child, (IPTR)(keymenu = MUI_MakeObject(MUIO_Menuitem,”Keys”, 0,2,0)), End), End), End), */ /*MUIA_Family_Child, (IPTR) (xmenu=MUI_MakeObject(MUIO_Menuitem, “1″, 1,0,0,0)), End, MUIA_Family_Child, (IPTR) (ymenu=MUI_MakeObject(MUIO_Menuitem, “2″, 2,0,0,0)), End,*/ // MUIA_Family_Child, (IPTR) (quit = MenuitemObject, MUIA_Menuitem_Title, // “Quit”, MUIA_Menuitem_Shortcut, (IPTR) “Q”, End), // End, // End, /* MUIA_Application_Menustrip, (IPTR) MenuitemObject, MUIA_Family_Child, (IPTR) MenuitemObject, MUIA_Menuitem_Title, “Rebulator”, MUIA_Family_Child, (IPTR)(infomenu = MenuitemObject, MUIA_Menuitem_Title, “About”, MUIA_Menuitem_Shortcut, (IPTR) “A”, End), MUIA_Family_Child, (IPTR)(quitmenu = MenuitemObject, MUIA_Menuitem_Title, (MSG_PROTECTION),MUIA_Menuitem_Shortcut, (IPTR) “P”, End), MUIA_Family_Child, (IPTR)(toolmenu = MenuitemObject, MUIA_Menuitem_Title, (MSG_TOOLTYPES),MUIA_Menuitem_Shortcut, (IPTR) “T”, End), MUIA_Family_Child, (IPTR) MenuitemObject, MUIA_Menuitem_Title, ~0, End, MUIA_Family_Child, (IPTR) (aboutmenu = MenuitemObject, MUIA_Menuitem_Title, (MSG_ABOUT), (IPTR) MUIA_Menuitem_Shortcut, (IPTR) “?”, End), MUIA_Family_Child, (IPTR) MenuitemObject, MUIA_Menuitem_Title, ~0, End, MUIA_Family_Child, (IPTR) (quit = MenuitemObject, MUIA_Menuitem_Title, (MSG_QUIT), MUIA_Menuitem_Shortcut, (IPTR) “Q”, End), End, End,*/ SubWindow, window1 = WindowObject, MUIA_Window_Title, “Li’lCalculator”, //MUIA_Window_SizeGadget, FALSE, MUIA_Text_SetVMax, FALSE, WindowContents, VGroup, Child, VGroup,//FRAME VISORE MUIA_Frame, MUIV_Frame_Group, Child, risultato= TextObject, TextFrame, MUIA_Text_PreParse, “33r”, MUIA_Background, MUII_TextBack, MUIA_Text_Contents, “0″, End, End, Child, VGroup, MUIA_Frame, MUIV_Frame_Group, //PRIMA RIGA //MUIA_VertWeight,30, Child, HGroup, MUIA_VertWeight, 20, MUIA_Frame, MUIV_Frame_Group, MUIA_Group_SameSize, TRUE, Child, button_memr=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, MUIA_Text_HiChar, ‘r’, MUIA_ControlChar, ‘r’, MUIA_Text_Contents, “MR”, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 1, MUIA_Text_SetVMax, FALSE, MUIA_InnerBottom, 0, MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Child, button_memc=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, MUIA_Text_HiChar, ‘c’, MUIA_ControlChar, ‘c’, MUIA_Text_Contents, “MC”, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 2, MUIA_Text_SetVMax, FALSE, MUIA_InnerBottom, 0, MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Child, button_memp=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, //MUIA_Text_HiChar, ‘p’, MUIA_ControlChar, ‘p’, MUIA_Text_Contents, “M+”, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 3, MUIA_Text_SetVMax, FALSE, MUIA_InnerBottom, 0, MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Child, button_memm=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, //MUIA_Text_HiChar, ‘m’, MUIA_ControlChar, ‘m’, MUIA_Text_Contents, “M-”, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 4, MUIA_Text_SetVMax, FALSE, MUIA_InnerBottom, 0, MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Child, button_canc=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, MUIA_Text_HiChar, ‘a’, MUIA_ControlChar, ‘a’, MUIA_Text_Contents, “CA”, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 5, MUIA_Text_SetVMax, FALSE, MUIA_InnerBottom, 0, MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Child, button_ce=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, MUIA_Text_HiChar, ‘e’, MUIA_ControlChar, ‘e’, MUIA_Text_Contents, “CE”, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 6, MUIA_Text_SetVMax, FALSE, MUIA_InnerBottom, 0, MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, End,//HGROUP Child, HGroup, //ESTERNO //MUIA_Group_SameSize, TRUE, //MUIA_HorizWeight, 50, Child, VGroup,//NUMERI MUIA_HorizWeight, 500, Child, HGroup, Child, button_seven=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, // MUIA_Text_HiChar, ’7′, MUIA_ControlChar, ’7′, MUIA_Text_Contents, “7″, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 6, MUIA_Text_SetVMax, FALSE, //MUIA_InnerBottom, 0, //MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Child, button_eight=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, // MUIA_Text_HiChar, ’8′, MUIA_ControlChar, ’8′, MUIA_Text_Contents, “8″, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 7, MUIA_Text_SetVMax, FALSE, //MUIA_InnerBottom, 0, //MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Child, button_nine=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, // MUIA_Text_HiChar, ’9′, MUIA_ControlChar, ’9′, MUIA_Text_Contents, “9″, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 8, MUIA_Text_SetVMax, FALSE, //MUIA_InnerBottom, 0, //MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, End, //FINE PRIMA RIGA NUMERI Child, HGroup,//SECONDA RIGA NUMERI //MUIA_Group_SameSize, TRUE, Child, button_four=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, // MUIA_Text_HiChar, ‘*’, MUIA_ControlChar, ’4′, MUIA_Text_Contents, “4″, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 11, MUIA_Text_SetVMax, FALSE, //MUIA_InnerBottom, 0, //MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Child, button_five=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, // MUIA_Text_HiChar, ‘*’, MUIA_ControlChar, ’5′, MUIA_Text_Contents, “5″, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 12, MUIA_Text_SetVMax, FALSE, //MUIA_InnerBottom, 0, //MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Child, button_six=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, // MUIA_Text_HiChar, ‘*’, MUIA_ControlChar, ’6′, MUIA_Text_Contents, “6″, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 13, MUIA_Text_SetVMax, FALSE, //MUIA_InnerBottom, 0, //MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, End, //FINE SECONDA RIGA Child, HGroup,//TERZA RIGA //MUIA_Group_SameSize, TRUE, Child, button_one=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, // MUIA_Text_HiChar, ‘*’, MUIA_ControlChar, ’1′, MUIA_Text_Contents, “1″, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 16, MUIA_Text_SetVMax, FALSE, //MUIA_InnerBottom, 0, //MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Child, button_two=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, // MUIA_Text_HiChar, ‘*’, MUIA_ControlChar, ’2′, MUIA_Text_Contents, “2″, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 17, MUIA_Text_SetVMax, FALSE, //MUIA_InnerBottom, 0, //MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Child, button_three=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, // MUIA_Text_HiChar, ‘*’, MUIA_ControlChar, ’3′, MUIA_Text_Contents, “3″, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 18, MUIA_Text_SetVMax, FALSE, //MUIA_InnerBottom, 0, //MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, End, //FINE TERZA RIGA Child, HGroup,//QUARTA //MUIA_Group_SameSize, TRUE, Child, button_zero=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, // MUIA_Text_HiChar, ‘*’, MUIA_ControlChar, ’0′, MUIA_Text_Contents, “0″, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 21, MUIA_Text_SetVMax, FALSE, //MUIA_InnerBottom, 0, //MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Child, button_dzero=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, // MUIA_Text_HiChar, ‘*’, MUIA_ControlChar, ‘d’, MUIA_Text_Contents, “00″, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, //MUIA_CycleChain, 21, MUIA_Text_SetVMax, FALSE, //MUIA_InnerBottom, 0, //MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Child, button_point=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, // MUIA_Text_HiChar, ‘*’, MUIA_ControlChar, ‘.’, MUIA_Text_Contents, “.”, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 22, MUIA_Text_SetVMax, FALSE, //MUIA_InnerBottom, 0, //MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, End, //FINE QUARTA RIGA End, //FINE VGROUP CIFRE Child, VGroup,//operazioni MUIA_HorizWeight,150, Child, button_minus=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, // MUIA_Text_HiChar, ‘*’, MUIA_ControlChar, ‘-’, MUIA_Text_Contents, “-”, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 19, MUIA_Text_SetVMax, FALSE, //MUIA_InnerBottom, 0, //MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Child, button_mul=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, // MUIA_Text_HiChar, ‘*’, MUIA_ControlChar, ‘*’, MUIA_Text_Contents, “*”, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 9, MUIA_Text_SetVMax, FALSE, //MUIA_InnerBottom, 0, //MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Child, button_div=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, // MUIA_Text_HiChar, ‘*’, MUIA_ControlChar, ‘/’, MUIA_Text_Contents, “/”, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 14, MUIA_Text_SetVMax, FALSE, //MUIA_InnerBottom, 0, //MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Child, button_plus=TextObject, MUIA_VertWeight, 200, ButtonFrame, MUIA_Font, MUIV_Font_Button, // MUIA_Text_HiChar, ‘*’, MUIA_ControlChar, ‘+’, MUIA_Text_Contents, “+”, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 24, MUIA_Text_SetVMax, FALSE, //MUIA_InnerBottom, 0, //MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, End, //VGROUP OPERATORI Child, VGroup, // SECONDA COLONNA OPERATORI //Child, MUIA_HorizWeight, 20, Child, button_minplus=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, //MUIA_Text_HiChar, ‘ ‘, //MUIA_ControlChar, ’7′, MUIA_Text_Contents, “±”, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 10, MUIA_Text_SetVMax, FALSE, //MUIA_InnerBottom, 0, //MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Child, button_perc=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, // MUIA_Text_HiChar, ‘*’, MUIA_ControlChar, ‘%’, MUIA_Text_Contents, “%”, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 15, MUIA_Text_SetVMax, FALSE, //MUIA_InnerBottom, 0, //MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Child, button_sqrt=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, // MUIA_Text_HiChar, ‘*’, MUIA_ControlChar, ‘s’, MUIA_Text_Contents, “s”, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 20, MUIA_Text_SetVMax, FALSE, //MUIA_InnerBottom, 0, //MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Child, button_enter=TextObject, MUIA_VertWeight, 200, ButtonFrame, MUIA_Font, MUIV_Font_Button, // MUIA_Text_HiChar, ‘*’, MUIA_ControlChar, ‘=’, MUIA_Text_Contents, “=”, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 23, MUIA_Text_SetVMax, FALSE, //MUIA_InnerBottom, 0, //MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, End, Child, VGroup, Child, button_inverse=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, // MUIA_Text_HiChar, ‘*’, MUIA_ControlChar, ‘i’, MUIA_Text_Contents, “1/x”, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 25, MUIA_Text_SetVMax, FALSE, //MUIA_InnerBottom, 0, //MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Child, button_logx=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, // MUIA_Text_HiChar, ‘*’, //MUIA_ControlChar, ”, MUIA_Text_Contents, “log”, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 25, MUIA_Text_SetVMax, FALSE, //MUIA_InnerBottom, 0, //MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Child, button_xn=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, // MUIA_Text_HiChar, ‘*’, //MUIA_ControlChar, ”, MUIA_Text_Contents, “pow”, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 25, MUIA_Text_SetVMax, FALSE, //MUIA_InnerBottom, 0, //MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Child, button_sinx=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, // MUIA_Text_HiChar, ‘*’, //MUIA_ControlChar, ”, MUIA_Text_Contents, “sin”, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 25, MUIA_Text_SetVMax, FALSE, //MUIA_InnerBottom, 0, //MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, Child, button_cosx=TextObject, ButtonFrame, MUIA_Font, MUIV_Font_Button, // MUIA_Text_HiChar, ‘*’, //MUIA_ControlChar, ”, MUIA_Text_Contents, “cos”, MUIA_Text_PreParse, “33c”, MUIA_InputMode, MUIV_InputMode_RelVerify, MUIA_Background, MUII_ButtonBack, MUIA_CycleChain, 25, MUIA_Text_SetVMax, FALSE, //MUIA_InnerBottom, 0, //MUIA_InnerTop, 0, //MUIA_FixHeightTxt, “MR”, //MUIA_FixWidth, 0, //MUIA_VertWeight, 0, End, End, //VGROUP SECONDA COLONNA OPERATORI End, //HGroup End, //FRAME (vgroup) End, //vgroup End, //windowobject End; /*applicationobject*/ if (application1!= NULL) { ULONG dahook, sigs= 0; DoMethod(window1, MUIM_Notify, MUIA_Window_CloseRequest, TRUE, (IPTR)application1, 2, MUIM_Application_ReturnID, MUIV_Application_ReturnID_Quit); DoMethod(button_one, MUIM_Notify, MUIA_Pressed, FALSE, (IPTR)application1, 2, MUIM_Application_ReturnID, ID_ONE); DoMethod(button_two, MUIM_Notify, MUIA_Pressed, FALSE, (IPTR)application1, 2, MUIM_Application_ReturnID, ID_TWO); DoMethod(button_three, MUIM_Notify, MUIA_Pressed, FALSE, (IPTR)application1, 2, MUIM_Application_ReturnID, ID_THREE); DoMethod(button_four, MUIM_Notify, MUIA_Pressed, FALSE, (IPTR)application1, 2, MUIM_Application_ReturnID, ID_FOUR); DoMethod(button_five, MUIM_Notify, MUIA_Pressed, FALSE, (IPTR)application1, 2, MUIM_Application_ReturnID, ID_FIVE); DoMethod(button_six, MUIM_Notify, MUIA_Pressed, FALSE, (IPTR)application1, 2, MUIM_Application_ReturnID, ID_SIX); DoMethod(button_seven, MUIM_Notify, MUIA_Pressed, FALSE, (IPTR)application1, 2, MUIM_Application_ReturnID, ID_SEVEN); DoMethod(button_eight, MUIM_Notify, MUIA_Pressed, FALSE, (IPTR)application1, 2, MUIM_Application_ReturnID, ID_EIGHT); DoMethod(button_nine, MUIM_Notify, MUIA_Pressed, FALSE, (IPTR)application1, 2, MUIM_Application_ReturnID, ID_NINE); DoMethod(button_zero, MUIM_Notify, MUIA_Pressed, FALSE, (IPTR)application1, 2, MUIM_Application_ReturnID, ID_ZERO); DoMethod(button_point, MUIM_Notify, MUIA_Pressed, FALSE, (IPTR)application1, 2, MUIM_Application_ReturnID, ID_POINT); DoMethod(button_canc, MUIM_Notify, MUIA_Pressed, FALSE, (IPTR)application1, 2, MUIM_Application_ReturnID, ID_CANC); DoMethod(button_ce, MUIM_Notify, MUIA_Pressed, FALSE, (IPTR) application1, 2, MUIM_Application_ReturnID, ID_CE); DoMethod(button_enter, MUIM_Notify, MUIA_Pressed, FALSE, (IPTR)application1, 2, MUIM_Application_ReturnID, ID_ENTER); DoMethod(button_minus, MUIM_Notify, MUIA_Pressed, FALSE, (IPTR)application1, 2, MUIM_Application_ReturnID, ID_MINUS); DoMethod(button_plus, MUIM_Notify, MUIA_Pressed, FALSE, (IPTR)application1, 2, MUIM_Application_ReturnID, ID_PLUS); DoMethod(button_mul, MUIM_Notify, MUIA_Pressed, FALSE, (IPTR)application1, 2, MUIM_Application_ReturnID, ID_MUL); DoMethod(button_div, MUIM_Notify, MUIA_Pressed, FALSE, (IPTR)application1, 2, MUIM_Application_ReturnID, ID_DIV); DoMethod(button_minplus, MUIM_Notify, MUIA_Pressed, FALSE, (IPTR)application1, 2, MUIM_Application_ReturnID, ID_MINPL); DoMethod(button_memp, MUIM_Notify, MUIA_Pressed, FALSE, (IPTR)application1, 2, MUIM_Application_ReturnID,ID_MEMP); DoMethod(button_memc, MUIM_Notify, MUIA_Pressed, FALSE, (IPTR)application1, 2, MUIM_Application_ReturnID, ID_MEMC); DoMethod(button_memr, MUIM_Notify, MUIA_Pressed, FALSE, (IPTR)application1, 2, MUIM_Application_ReturnID, ID_MEMR); DoMethod(button_memm, MUIM_Notify, MUIA_Pressed, FALSE, (IPTR)application1, 2, MUIM_Application_ReturnID, ID_MEMM); DoMethod(button_inverse, MUIM_Notify, MUIA_Pressed, FALSE, (IPTR)application1, 2, MUIM_Application_ReturnID, ID_INV); DoMethod(button_sqrt, MUIM_Notify, MUIA_Pressed, FALSE, (IPTR)application1, 2, MUIM_Application_ReturnID, ID_SQRT); DoMethod(button_perc, MUIM_Notify, MUIA_Pressed, FALSE, (IPTR)application1, 2, MUIM_Application_ReturnID, ID_PERC); DoMethod(button_dzero, MUIM_Notify, MUIA_Pressed, FALSE, (IPTR) application1, 2, MUIM_Application_ReturnID, ID_DZERO); DoMethod(button_sinx, MUIM_Notify, MUIA_Pressed, FALSE, (IPTR) application1, 2, MUIM_Application_ReturnID, ID_SINX); DoMethod(button_cosx, MUIM_Notify, MUIA_Pressed, FALSE, (IPTR) application1, 2, MUIM_Application_ReturnID, ID_COSX); DoMethod(button_xn, MUIM_Notify, MUIA_Pressed, FALSE, (IPTR) application1, 2, MUIM_Application_ReturnID, ID_XN); DoMethod(button_logx, MUIM_Notify, MUIA_Pressed, FALSE, (IPTR) application1, 2, MUIM_Application_ReturnID, ID_LOGX); DoMethod(infomenu, MUIM_Notify, MUIA_Menuitem_Trigger, MUIV_EveryTime, (IPTR) application1, 2, MUIM_Application_ReturnID, MEN_ABOUT); DoMethod(quit, MUIM_Notify, MUIA_Menuitem_Trigger, MUIV_EveryTime, (IPTR) application1, 2, MUIM_Application_ReturnID, MUIV_Application_ReturnID_Quit); set(window1, MUIA_Window_Open, TRUE); while ((dahook= (LONG)DoMethod(application1, MUIM_Application_NewInput, (IPTR)&sigs))!= MUIV_Application_ReturnID_Quit) { switch (dahook) { case ID_ONE: { if (stato==NORMAL) { fprimo=strngfy(str_buf_primo, “1″); set(risultato, MUIA_Text_Contents, (IPTR)str_buf_primo); } else { if (((stato!=ERROR)&&(stato!=STANDBY))&&(statoprec!=STANDBY)) { fsecondo=strngfy(str_buf_secondo, “1″); set(risultato, MUIA_Text_Contents, (IPTR)str_buf_secondo); } } lastfkey=K_ONE; break; } case ID_TWO: { if (stato==NORMAL) { fprimo=strngfy(str_buf_primo, “2″); set(risultato, MUIA_Text_Contents, (IPTR)str_buf_primo); } else { if (((stato!=ERROR)&&(stato!=STANDBY))&&(statoprec!=STANDBY)) { fsecondo=strngfy(str_buf_secondo, “2″); set(risultato, MUIA_Text_Contents, (IPTR)str_buf_secondo); } } lastfkey=K_TWO; break; } case ID_THREE: { if (stato==NORMAL) { fprimo=strngfy(str_buf_primo, “3″); set(risultato, MUIA_Text_Contents, (IPTR)str_buf_primo); } else { if (((stato!=ERROR)&&(stato!=STANDBY))&&(statoprec!=STANDBY)) { fsecondo=strngfy(str_buf_secondo, “3″); set(risultato, MUIA_Text_Contents, (IPTR)str_buf_secondo); } } lastfkey=K_THREE; break; } case ID_FOUR: { if (stato==NORMAL) { fprimo=strngfy(str_buf