Newsgroup: it.comp.lang.c++
Titolo: da interfaccia grafica a console

ho un problema: ho una applicazione scritta con C++ Builder, consiste
di una interfaccia grafica con bottoni, menù, finestre di testo da
riempire ecc, io ho bisogno di creare una applicazione da console che
mi esegua parte dell'elaborazione dell'applicazione di origine e
vorrei passare da riga di comando le informazioni necessarie.
E' la prima volta che vedo il codice di una applicazione con
interfaccia grafica e non mi raccapezzo tra i vari oggetti, metodi e
librerie del Borland, qualcuno può consigliarmi come impostare il mio
lavoro, non so proprio da dove iniziare!!
Grazie mille
Nicola

 lavoro, non so proprio da dove iniziare!!
Beh, devi identificare se questa applicazione ha un suo subset di classi 
che svolgono le varie funzionalità che ti interessano a te, o se è stato 
messo tutto dietro ai vari metodi, altrimenti il primo step è quello di 
isolare la logica, o altrimenti se non hai molto tempo da dedicare al 
progetto, la cosa più immediata può essere quello di estendere la main 
form utilizzata dal progetto, e far si che si auto piloti quando riceve 
l'input da riga di comando..
cod


grazie mille per la dritta, date le mie scarse qualità di programatore
posso chiedere ulteriori spiegazioni sulla tua seconda opzione. Per
estendere la main form intendi in senso stretto creare una classe
derivata da main form? nel progetto in borland mi sembra tutto così
strano per me che ho solo visto applicazioni da console!

 strano per me che ho solo visto applicazioni da console!
Beh, non credo ti convenga estendere la main form come classe, anche 
perchè quelle classi sono allocate a runtime dal motore della VCL .. 
diciamo che borland per far digerire alcuni concetti del delphi al C++ 
ha fatto un pò di modifiche..
Secondo me ti converrebbe nell'OnFormLoad della tua main form 
controllare se ci sono argomenti, e da lì iniziare a scrivere il codice 
per pilotare la classe stessa... sempre che chi abbia scritto quella 
applicazione non abbia inserito il core in delle classi c++ senza 
ricorrere alla VCL..
riuscito ad identificare quelle classi?
cod

non ho capito molto quello che mi hai detto comunque ti spiego meglio,
scusa la totale mancanza di competenze riguarco c++ e Borland c++
Builder:
nella classe "class TFormMain : public TForm", c'è un metodo "void
__fastcall TFormMain::Elaborazione(){....."
qua dentro c'è il grosso di quello che mi serve richiamare da riga di
comando, all'interno vengono richiamati metodi su oggetti di classi
definite in altri file del progetto e vengono sfruttati dati presenti
in campi di testo e in menù a tendina presenti sulla interfaccia
grafica. Diciamo che quello che fa l'applicazione l'ho capito, che
metodi chiama, che informazioni usa, ma vorrei sfruttare qualche cosa
del Borland che mi permetta di ricompilare il tutto in un applicazione
da console e quindi che serializzi un po' tutte le operazioni. Del
tipo un file cpp all'interno del progetto che possa instanziare gli
oggetti che mi servono e chiamare funzioni tipo "void __fastcall
TFormMain::Elaborazione(){....." e poi compilare e linkare il solo
file cpp che ho creato, in modo da avere questo eseguibile che mi
servirà a sua volta per lanciare l'applicazione da un altro programma,
scritto in c, che già ho.
Immagino che avrai capito poco di quello che ti ho detto! se hai
capito e sai come aiutarmi ti giuro che ti metto tra i ringraziamenti
della mia tesi!!!

 da console e quindi che serializzi un po' tutte le operazioni.
In automatico non è possibile. Per creare invece un'applicazione 
console basta creare un nuovo progetto, selezionare il "Console 
wizard", impostare il linguaggio al C++ e fine, o meglio, da lì 
puoi cominciare.
Il problema è che tutti i dati letti dai controlli di Windows 
(edit, menù, ecc.) devi andare a prenderli da qualche parte: 
input dell'utente, parametri della riga di comando, da file, 
ecc. Quindi fondamentalmente devi decidere come fare questo e 
convertire manualmente le relative parti. Fatto quello puoi 
utilizzare i metodi esattamente come ora.
Se sia complicato o no dipende tutto da come è organizzato il 
progetto attuale e dalla quantità di variabili in gioco.
HTH,
-- 
Stefano Frosio
www.esse-effe.com

so che è una porcata... ma fare un programma C o c++ a riga di comando 
che lancia il tuo applicativo e con sendmessage e derivati "preme" i 
bottoni giusti ... nn va bene ? Magari nn è bello ... ma funge :)
ciao
PP
Stefano Frosio ha scritto:


per dovere di cronaca racconto che sto facendo:
mi sono creato un nuovo progetto col il Console Wizard del Borland,
col Project Manager ho aggiunto al mio nuovo progetto tutti i file cpp
e lib dell'applicazione, nel file con il classico main ho copiato il
codice della funzione "void
__fastcall TFormMain::Elaborazione(){....." e ora a mano cerco di
inserire tutte le info che venivano prese dai vari form e spero che
prima o poi uscirò da questo labirinto.
Qual è il santo patrono dei programmatori per potermi appellare nei
momenti di sconforto?
Nicola Snaporaz

 per dovere di cronaca racconto che sto facendo:
Non ti invidio. Io pero' cercherei di fare modifiche con continuita' 
ovvero avere la possibilità di eseguire il codice ad ogni modifica. 
Quando finalmente riuscirai a compilare, se ti accorgi che non funziona 
e' difficile avere idea di dove mettere le mani.
Potresti pensare di ridirezionare i parametri sulla riga di comando un 
po' alla volta. Immagino che anche l'applicazione a finestre accetti i 
parametri da riga di comando, o in ogni caso li potresti simulare.
E.

 e' difficile avere idea di dove mettere le mani.
Sto facendo così, cambio qualcosa, compilo e vedo se diminuiscono gli
errori,non è il massimo dell'efficenza ma lentamente avanzo.
Grazie per la comprensione!!!!
Nicola Snaporaz

 glierrori,non è il massimo dell'efficenza ma lentamente avanzo.
Il numero di errori, purtroppo, non e' per nulla proporzionale alla
correttezza del codice, e neppure alla semplice correttezza
sintattica. Vale solo la regola Compila -> Corretto sintatticamente /
Non compila -> Non corretto sintatticamente. 5 errori non sono meglio
di 200, perche' 5 errori "gravi" (che arrestano la compilazione)
possono nasconderne altre migliaia (dopo il punto d'arresto), e 200
errori possono essere derivati da un'unica dichiarazione errata. Se
vuoi testare la correttezza sintattica a fronte di refactoring, il
codice dev'essere sempre compilabile (o almeno devono esserlo le
unita' di compilazione singolarmente), cioe' ad ogni passo devi
riportarti a zero errori (o a soli errori di linking, che cercherai di
eliminare al passo successivo).
Tutto questo pippotto solo per dirti che, per come stai procedendo, e'
assolutamente ininfluente se il numero di errori cala o cresce. Per
rincuorarti ti dico che, se correggi sempre il primo errore, il
processo va a convergenza :)
--*PaN!*
 
-- 
I'm using an evaluation license of nemo since 59 days.
You should really try it!
http://www.malcom-mac.com/nemo

 --*PaN!*
Hai pienamente ragione, il conto degli errori era solo un modo di
comodo per procedere in modo lento ma inesorabile, infatti la
convergenza è arrivata ieri sera.
Per fortuna il codice era ben fatto e risolto il problema delle info
da passare da riga di comando o con valori di defoult le cose sono
andate lisce come l'olio.
Grazie mille a tutti per l'interessamento, penso che ci risentiremo
perchè non credo che i problemi della mia tesi finiranno qua!
Ciao a tutti

 processo va a convergenza :)
In effetti un numero finito di righe di codice possono contenere solo un
numero finito di errori...
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 numero finito di errori...
Si potrebbe obiettare che concettualmente il seguente programma:
---
a.h
---
unt o;
#include "a.h"
-----
a.cpp
-----
#include "a.h"
int main() {}
Ne contiene un numero infinito ;-)
Ciao,
Nicola

 Si potrebbe obiettare che concettualmente il seguente programma:
Mi chiedo se formalmente sia un programma. Un algoritmo deve avere
lunghezza finita, e immagino che questo requisito sia ragionevole anche
per un programma.
Ma credo che il problema della finitezza del programma sia chiave.
Se ammettiamo programmi infiniti, allora ci salta chiaramente
l'enumerabilità dell'insieme dei programmi *e* non possiamo più
costruire una macchina di turing universale in grado di eseguire tutti i
programmi.
IMHO un programma infinito non è calcolabile, in definitiva. Ma ho
buttato tutto su, sarebbe da meditarci fuori ora di pasto :)


 processo va a convergenza :)
Non è detto che sia possibile correggere un errore senza modificare il 
codice che precede il punto in cui c'e' l'errore. Quindi può capitare di 
  oscillare all'infinito tra gli stessi due errori.
E.

  Ne contiene un numero infinito ;-)
Piu' che altro "genera" un numero infinito di errori, o ancor
meglio"non termina". Di errori ne contiene solo due =)
--*PaN!*
 
-- 
I'm using an evaluation license of nemo since 62 days.





Correggere un errore e' diverso da "farlo sparire" =)
Senza dare una definizione formale di "correzione", tiro giu' un
esempio:
Es.
struct A { int a; };
struct B { int b; };
	A x;
[...]
	cout << x.a;
	cout << x.b;
Spero che nessuno sano di mente possa pensare che "correggere" il
problema sia cambiare il tipo della variabile X da A a B e vice
versa... all'infinito! =)
--
Marco
PS: giuro che non volevo tirar fuori un teorema, ma dare un sostegno
morale all'OP! ;)
 
-- 
I'm using an evaluation license of nemo since 62 days.


   oscillare all'infinito tra gli stessi due errori.
Se proprio vogliamo essere formali, si pone il problema di definire cosa
sia un errore e cosa sia una correzione.
Il problema è che mentre definire l'errore può essere fatto banalmente
(per esempio un errore di sintassi, un undefined behaviour), è molto più
scomodo definire il concetto di 'correzione'. In particolare perchè per
definire la correzione bisogna dare la semantica intesa del programma
'corretto'.
Limitandoci agli errori di sintassi (e intendendo con programma corretto
un programma sintatticamente corretto) la soluzione è banale e si fa in
O(1): seghiamo tutte le parti di programma tranne la main (che diventa
vuota). Il programma è certamente sintatticamente corretto. Eppure poco
interessante. 
Se poi ci spostiamo appena sopra e consideriamo che:
1. in generale la correttezza sintattica di C (contrariamente a quello
che molti pensano) *NON* è esprimibile come grammatica libera dal
contesto.
2. il C++ è turing completo a compile time,
3. ci sono aspetti perfino della tipizzazione che non sono risolvibili a
compile time
diciamo che la faccenda diviene piuttosto problematica. Senza tenere
conto che normalmente un programma è corretto avendo proprietà molto più
forti della semplice correttezza sintattica e che, ovviamente, quasi
nessuno si mette a dare la semantica formalizzata di un programma. E se
anche lo si deve fare, diventa ragionevolmente agevole farlo per un
linguaggio funzionale *puro*. Per un linguaggio imperativo è
sufficientemente noioso, non parliamo di uno ad oggetti e di uno
complesso come C++.


 sia un errore e cosa sia una correzione.
Beh, sappiamo che non č sempre possibile dimostrare la correttezza di un 
programma. Io con "correzione" intendevo quella sintattica ovvero: viene 
compilato senza errori. Questo era anche quello che penso intendesse 
l'OP, visto che si voleva dimostrare che correggendo ogni volta il primo 
errore alla fine si sarebbe ottenuta una compilazione senza errori.
Correggere un errore significherebbe, in questo caso, far sě che il 
compilatore non riporti piů quell'errore alla successiva compilazione.
E.

 compilatore non riporti più quell'errore alla successiva compilazione.
Allora il processo non solo converge, ma non è neppure iterativo. Io ho
descritto pure l'algoritmo :)
Come dicevo, il problema è che il metodo da me proposto è efficace solo
perchè stiamo usando una versione parecchio ristretta del concetto di
'correttezza'. Voglio dire, è un discorso valido e rigoroso, anche se
poco utile all'atto pratico. :)


 descritto pure l'algoritmo :)
...questa discussione č altamente insensata... evidentemente non ci sono 
altri messaggi interessanti sul NG. Comunque insisto: se correggi un 
errore potresti pero' causare un errore diverso. Eventualmente anche ad 
una riga precedente all'errore corretto.
E.

 una riga precedente all'errore corretto.
Certo che è insensata! È quella che si suol dire una sega mentale.
Basta vedere che il mio metodo (che per inciso non è suscettibile al
problema che dici tu, poichè *non* esiste una riga prima) è in O(1).
