* * * *

Privacy Policy

Blog italiano

Clicca qui se vuoi andare al blog italiano su Lazarus e il pascal.

Forum ufficiale

Se non siete riusciti a reperire l'informazione che cercavate nei nostri articoli o sul nostro forum vi consiglio di visitare il
Forum ufficiale di Lazarus in lingua inglese.

Lazarus 1.0

Trascinare un file nel programma
DB concetti fondamentali e ZeosLib
Recuperare codice HTML da pagina web
Mandare mail con Lazarus
Stabilire il sistema operativo
Esempio lista in pascal
File INI
Codice di attivazione
Realizzare programmi multilingua
Lavorare con le directory
Utilizzare Unità esterne
TTreeView
TTreeview e Menu
Generare controlli RUN-TIME
LazReport, PDF ed immagini
Intercettare tasti premuti
Ampliare Lazarus
Lazarus e la crittografia
System Tray con Lazarus
UIB: Unified Interbase
Il file: questo sconosciuto
Conferma di chiusura di un applicazione
Liste e puntatori
Overload di funzioni
Funzioni a parametri variabili
Proprietà
Conversione numerica
TImage su Form e Panel
Indy gestiore server FTP lato Client
PopUpMenu sotto Pulsante (TSpeedButton)
Direttiva $macro
Toolbar
Evidenziare voci TreeView
Visualizzare un file Html esterno
StatusBar - aggirare l'errore variabile duplicata
Da DataSource a Excel
Le permutazioni
Brute force
Indy 10 - Invio email con allegati
La gestione degli errori in Lazarus
Pascal Script
Linux + Zeos + Firebird
Dataset virtuale
Overload di operatori
Lavorare con file in formato JSON con Lazarus
Zeos ... dietro le quinte (prima parte)
Disporre le finestre in un blocco unico (come Delphi)
Aspetto retrò (Cmd Line)
Lazarus 1.0
Come interfacciare periferica twain
Ubuntu - aggiornare free pascal e lazarus
fpcup: installazioni parallele di lazarus e fpc
Free Pascal e Lazarus sul Raspberry Pi
Cifratura: breve guida all'uso dell'algoritmo BlowFish con lazarus e free pascal.
Creare un server multithread
guida all'installazione di fpc trunk da subversion in linux gentoo
Indice
DB concetti fondamentali e connessioni standard
Advanced Record Syntax
DB concetti fondamentali e DBGrid
DB concetti fondamentali e TDBEdit, TDBMemo e TDBText
Advanced Record Syntax: un esempio pratico
Superclasse form base per programmi gestionali (e non)
Superclasse form base per programmi gestionali (e non) #2 - log, exception call stack, application toolbox
Superclasse form base per programmi gestionali (e non) #3 - traduzione delle form
Superclasse form base per programmi gestionali (e non) #4 - wait animation
Un dialog per la connessione al database:TfmSimpleDbConnectionDialog
Installare lazarus su mac osx sierra
immagine docker per lavorare con lazarus e free pascal
TDD o Test-Driven Development
Benvenuto! Effettua l'accesso oppure registrati.
Gennaio 17, 2022, 08:54:47 am

Inserisci il nome utente, la password e la durata della sessione.

29 Visitatori, 1 Utente
 

Autore Topic: [RISOLTO] Porting componenti fatti x Delphi  (Letto 321 volte)

DragoRosso

  • Scrittore
  • Sr. Member
  • *****
  • Post: 445
  • Karma: +7/-0
  • Prima ascoltare, poi decidere
[RISOLTO] Porting componenti fatti x Delphi
« il: Aprile 16, 2021, 11:10:38 am »
Salve, come nuovo utente di Lazarus stò passando pian piano i progetti sviluppati con il più celebre "antagonista" appunto in FPC / Lazarus.

Prime "cose" da passare sono ovviamente tutte le utility e gli add-on che un progetto normalmente usa e che non fanno parte dell'ambiente integrato.

Alcuni pacchetti sono fortunatamente compatibili, tipo JVC e parte di JCL, altri invece no sopratutto quelli un pò più vecchietti.

In questo momento stò portando un pacchetto per la gestione delle seriali di comunicazione (uno dei tanti TComPort) ed effettivamente ho riscontrato delle difficoltà (già superate, il primo progetto è già in Lazarus e funziona alla grande) che mi hanno fatto un pò riflettere.

Inanzitutto sono diventato matto all'inizio perchè mi venivano segnalati degli errori riguardanti delle semplici chiamate a funzioni che risultavano dichiarate in modo impeccabile e che invece fpc mi "segnalava" come incorrette.

Esplorando un pò più a fondo, ho scoperto che a fpc non piace, e su questo gli dò assolutamente e piena ragione, che variabili locali o parametri di una funzione siano chiamate come nomi di proprietà definite nella classe (anche se definite diversamente).

Ovviamente a Delphi non fà ne caldo ne freddo, va bene tutto (mi pare di tornare al vecchio Basic dove potevi assegnare una stringa a una variabile numerica  :'( ).

Fermo restando che non mi sarebbe mai passato per la testa di fare qualcosa di simile, ossia usare come nome di variabile il nome di una proprietà, secondo le regole standardizzate del PASCAL è possibile usare nomi di variabili identiche a nomi di proprietà (sempre all'interno della stessa classe ovviamente) ?

Si sà che variabili globali vengono nascoste da variabili locali con lo stesso nome.

E' solo uno sfizio "per sapere", già per mio modo di fare neanche le variabili locali hanno mai un nome uguale a qualsiasi altra variabile globale o definite in una classe, anche perchè le minime regole di definizione delle variabili già impediscono che questo accada (Volume, fVolume,  lVolume, gVolume, etc ...).

P.S.: sò che c'è il pacchetto LazSerial per la gestione delle seriali, ma il componente che uso mi pare sia un pò più completo.

Un saluto a tutti
 
« Ultima modifica: Aprile 17, 2021, 03:01:14 pm da DragoRosso »
:) Ogni alba è un regalo, ogni tramonto è una conquista :)

nomorelogic

  • Global Moderator
  • Hero Member
  • *****
  • Post: 2571
  • Karma: +12/-3
Re:Porting componenti fatti x Delphi
« Risposta #1 il: Aprile 16, 2021, 12:46:14 pm »
con questo problema del nome delle variabili e dei parametri mi ci sono imbattuto anche io all'inizio e non capivo il motivo

poi l'illuminazione: il compilatore fpc ha diversi modi di compilare il pascal
il "delphi mode" attiva la compilazione, appunto, in modalità Delphi

se leggi in questo link, al punto 8
https://www.freepascal.org/docs-html/prog/progse74.html
vedrai che dovrebbe risolvere il tuo problema in quanto dovrebbe accettare che i parametri dei metodi di una classe, abbiano lo stesso nome delle proprietà

comunque bisogna ammettere che leggere il seguente codice:
Codice: [Seleziona]
procedure TClasseAAA.ImpostaTemp(Temperatura: double);
begin
  ...
  Temperatura := Temperatura;
  ...
end;

è ambiguo e la domanda potrebbe sorgere spontanea: assegno la proprietà dell'istanza o assegno il parametro?  :o
mentre il seguente non lascia spazio a fraintendimenti di lettura:

Codice: [Seleziona]
procedure TClasseAAA.ImpostaTemp(ATemperatura: double);
begin
  ...
  Temperatura := ATemperatura;
  ...
end;

Diciamo che la "A" come prefisso del nome del parametro del metodo, la puoi intendere come l'articolo indeterminativo "un" - :) -, per cui il tutto è molto più chiaro.


visto che ci siamo
a proposito delle dichiarazioni di metodi, funzioni e procedure:
a meno che non sia espressamente richiesto dal contesto, tutti i parametri dovrebbero essere const
(sopra non l'ho messo perché sennò non ci sarebbe stata l'ambiguità  ;D )

Imagination is more important than knowledge (A.Einstein)

DragoRosso

  • Scrittore
  • Sr. Member
  • *****
  • Post: 445
  • Karma: +7/-0
  • Prima ascoltare, poi decidere
Re:Porting componenti fatti x Delphi
« Risposta #2 il: Aprile 16, 2021, 02:39:02 pm »
No, no, non ci sono problemi, anzi ho rivisto la classe TComPort e l'ho rimessa parzialmente a posto.
Non esiste proprio utilizzare nomi uguali per tutto.

MA IL DUBBIO NON E' STATO DIRIMATO ... SI POTREBBE FARE ? O è una libertà di Delphi ?

Dei vari modificatori mi sono documentato (aprendo un codice Lazarus è il primo define nuovo che leggi  :D ), però il fatto di usarlo come Delphi non se ne parla sarebbe un pò riduttivo, se Delphi permette questo.

L'unica cosa che secondo me si dovrebbe mettere a posto (a meno che non si possa già fare e sbagli io) è l'assegnazione degli eventi:
- creo un evento OnClick, e assegno questo evento a runtime a tutta una serie di componenti. Adesso come adesso con modalità "{$Mode objFPC}" devo assegnare all'evento il puntatore alla procedura. Questo però induce una possibile problematica (a parte l'odio di lavorare con i puntatori), ossia la procedura potrebbe non essere compatibile con quanto richiesto dall'evento e non viene controllato in fase di compilazione dando adito a possibili problematiche difficili poi da diagnosticare a runtime.

esempio:

Codice: [Seleziona]
//Procedura generica
procedure TForm1.JvLED1Click(Sender: TObject);
begin
  if Sender is TJvLed then
    (Sender as TJvLed).Status := not (Sender as TJvLed).Status;
end;

//Assegnazione attuale (senza controllo)
Led2.OnClick := @JvLED1Click;

//Assegnazione preferibile (con controllo, ma genera l'errore (Error: Wrong number of parameters specified for call to "JvLED1Click")
Led2.OnClick := JvLED1Click;

Saluti
:) Ogni alba è un regalo, ogni tramonto è una conquista :)

Stilgar

  • Global Moderator
  • Hero Member
  • *****
  • Post: 2241
  • Karma: +8/-0
Re:Porting componenti fatti x Delphi
« Risposta #3 il: Aprile 16, 2021, 03:47:47 pm »
Ciao.


Delphi nasconde la natura della callback.


Ma di fatto è un puntatore a metodo o procedura/funzione. Dipende da come è dichiarato il prototipo di chiamata.


Sul fatto che possa dare errore, mi sembra di ricordare, che controlla. Essendo un puntatore tipizzato ti castiga se passi un OnKeyUp al posto di un OnChange. Ma vado a memoria, potrei ricordarmi male.


Se poi fai un cast passando per puntatore generico, saresti solo masochista nel farlo :)


Che poi stia sulle scatole è una questione di gusti e quelli non si discutono.
Codice: [Seleziona]
{*
Led2.OnClick := JvLED1Click;
*}

[/size]Qui stai tentando di invocare il metodo e assegnare ad OnClick il risultato della chiamata. Il compilatore ti sta gentilmente chiedendo di passare un parametro in chiamata. Se mettessi un nil come parametro, mi aspetto che ti dica che la procedura non restituisce nulla nello stack.




Stilgar
« Ultima modifica: Aprile 16, 2021, 03:51:42 pm da Stilgar »
Al mondo ci sono 10 tipi di persone ... chi capisce il binario e chi no.

nomorelogic

  • Global Moderator
  • Hero Member
  • *****
  • Post: 2571
  • Karma: +12/-3
Re:Porting componenti fatti x Delphi
« Risposta #4 il: Aprile 16, 2021, 03:54:58 pm »
Mentre stavo scrivendo ha risposto Stilgar, ma la risposta la metto comunque (oramai l'ho scritta :D )





MA IL DUBBIO NON E' STATO DIRIMATO ... SI POTREBBE FARE ? O è una libertà di Delphi ?

forse non ho capito la domanda
il fatto è che il compilatore Delphi accetta quella sintassi (e di conseguenza la sua semantica)

fpc invece no, non ha quella sintassi (e secondo me è più corretto l'approccio di fpc)
però, vista la mole di codice Delphi a disposizione, hanno inventato la modalità Delphi di modo da poter compilare quel codice anche in progetti fpc
la modalità delphi, per concludere, la vedo utile solamente per fare il porting senza voler riscrivere con la sintassi di fpc

si tratta alla fine di una scelta del programmatore


L'unica cosa che secondo me si dovrebbe mettere a posto (a meno che non si possa già fare e sbagli io) è l'assegnazione degli eventi:
- creo un evento OnClick, e assegno questo evento a runtime a tutta una serie di componenti. Adesso come adesso con modalità "{$Mode objFPC}" devo assegnare all'evento il puntatore alla procedura. Questo però induce una possibile problematica (a parte l'odio di lavorare con i puntatori), ossia la procedura potrebbe non essere compatibile con quanto richiesto dall'evento e non viene controllato in fase di compilazione dando adito a possibili problematiche difficili poi da diagnosticare a runtime.

Beh, essendo l'evento un puntatore ad una procedura ho paura che non ci siano alternative.
Proprio per evitare i problemi di compilazione, molti metodi destinati ad essere assegnati come risposta ad un evento si aspettano un unico parametro Sender (vedi dichiarazione di TNotifyEvent).

Quindi l'assegnazione seguente
Codice: [Seleziona]
Led2.OnClick := @JvLED1Click;
E' corretta perché assegna all'evento OnClick l'indirizzo del metodo "JvLED1Click".


L'assegnazione sotto è errata per diversi motivi:
Codice: [Seleziona]
Led2.OnClick := JvLED1Click;

  • si sta assegnando al puntatore OnClick un valore che non arriverà mai perché una procedura non restituisce un valore
  • la procedura si aspetta un parametro ma nell'assegnazione il parametro non è stato passato

nomorelogic
Imagination is more important than knowledge (A.Einstein)

Stilgar

  • Global Moderator
  • Hero Member
  • *****
  • Post: 2241
  • Karma: +8/-0
Re:Porting componenti fatti x Delphi
« Risposta #5 il: Aprile 16, 2021, 03:58:36 pm »
La modalità Delphi la torvo più comoda con i template/generics




Dover creare inner class come se piovesse, non mi è molto simpatica.


Pensa alle Liste Generiche. L'iteratore è ridefinito dentro al generics.


Con la modalità delphi puoi avere 2 contenitori generici e definire 1 solo iteratore.


(Ripeto, stiamo parlando di gusti)




Stilgar
Al mondo ci sono 10 tipi di persone ... chi capisce il binario e chi no.

DragoRosso

  • Scrittore
  • Sr. Member
  • *****
  • Post: 445
  • Karma: +7/-0
  • Prima ascoltare, poi decidere
Re:Porting componenti fatti x Delphi
« Risposta #6 il: Aprile 16, 2021, 04:26:33 pm »
@Stilgar, @Nomorelogic

".Onclick" --- Non è un metodo ma una proprietà. Il metodo eventualmente sarebbe ".Click"

Scrivendo Led2.Onclick := .......      io non eseguo metodi, ma assegno qualcosa a una proprietà (poi cosa ci sia dietro, giustamente mi potrebbe essere "nascosto").

Per ciò che riguarda il puntatore, confermo che effettivamente c'è un controllo sul puntatore stesso quindi il problema è solo di estetica e di gusto.

Sull'argomento sintassi  e Delphi rimango d'accordo parzialmente:

1) Generics, containers, etc .... possono andare bene se non violano le regole basilari. Ovvio che nel pensiero di riscrivere tutto il codice, ci può stare che un occhio lo si chiuda.

2) Invece sul consentire l'assegnazione di nomi identici in "tutte le parti", quello non mi prende tanto. Si dà adito veramente a tanti possibili problemi in fase di runtime (io non l'ho mai fatto, tant'è vero che lo scopro adesso che FPC nativamente lo nega su componenti importati :) ).

Quello che mi piace, oltre al linguaggio PASCAL vero e proprio, e che praticamente a RUNTIME i problemi sono veramente ZERO o quasi, se si sfruttano le caratteristiche del linguaggio e non si usano scorciatoie.

Il debugger io lo uso più che altro per capire i "percorsi" legati alle chiamate, uso della memoria e simili e quindi ad ottimizzare il codice, piuttosto che per debuggare l'applicazione alla ricerca di BUG.

Ciao.


:) Ogni alba è un regalo, ogni tramonto è una conquista :)

Stilgar

  • Global Moderator
  • Hero Member
  • *****
  • Post: 2241
  • Karma: +8/-0
Re:Porting componenti fatti x Delphi
« Risposta #7 il: Aprile 16, 2021, 04:39:28 pm »
Sì, d'accordo OnClick è una property. Forse mi sono spiegato male.

Se togli @ nell'assegnazione, cosa capisce il compilatore?
Che vuoi invocare il metodo, non estrarne il puntatore. Quindi ti avvisa che hai dimenticato il parametro per invocare il metodo. Poi scazzerebbe lo stesso, visto che è una procedure al posto di una function.

Qui sto parlando di fpc.

Stilgar
Al mondo ci sono 10 tipi di persone ... chi capisce il binario e chi no.

DragoRosso

  • Scrittore
  • Sr. Member
  • *****
  • Post: 445
  • Karma: +7/-0
  • Prima ascoltare, poi decidere
Re:Porting componenti fatti x Delphi
« Risposta #8 il: Aprile 16, 2021, 04:50:50 pm »
@Stilgar
Effettivamente spiegato così mi ha un attimo aperto gli occhi. La scrittura che avevo proposto poteva essere (anzi è da FPC)  interpretata come dici tu (che tra l'altro è l'unico modo corretto di interpretazione).

Stò scoprendo che fino ad ora ho fatto un mucchio di schifezze (in realtà non tantissime però) dal punto di vista logico / semantico, e quel che mi rode di più e che mi veniva concesso di farle (anche se il risultato era quello voluto da me) !!!

Grazie per la discussione, non si finisce mai di imparare.

Sono sempre più convinto nel passare in toto a Lazarus.

Saluti
:) Ogni alba è un regalo, ogni tramonto è una conquista :)

DragoRosso

  • Scrittore
  • Sr. Member
  • *****
  • Post: 445
  • Karma: +7/-0
  • Prima ascoltare, poi decidere
Re:Porting componenti fatti x Delphi
« Risposta #9 il: Aprile 17, 2021, 12:28:51 am »
Qui spiegano tutto.
https://www.freepascal.org/docs-html/user/usersu86.html#x130-1370007.3.1

Citazione
Note that the -Mobjfpc mode switch is to a large degree Delphi compatible, but is more strict than Delphi. The most notable differences are:

1.
    Parameters or local variables of methods cannot have the same names as properties of the class in which they are implemented.
2.
    The address operator is needed when assigning procedural variables (or event handlers).
3.
    AnsiStrings are not switched on by default.
4.
    Hi/Lo functions in Delphi are always evaluated using a word argument, in FPC there are several overloaded versions of these functions, and therefor the actual type of the passed variable is used to determine which overload is called. This may result in different results.

E direi che più rigore và benissimo.
:) Ogni alba è un regalo, ogni tramonto è una conquista :)

 

Recenti

How To

Utenti
Stats
  • Post in totale: 15842
  • Topic in totale: 1946
  • Online Today: 29
  • Online Ever: 900
  • (Gennaio 21, 2020, 08:17:49 pm)
Utenti Online
Users: 1
Guests: 29
Total: 30

Disclaimer:

Questo blog non rappresenta una testata giornalistica poiché viene aggiornato senza alcuna periodicità. Non può pertanto considerarsi un prodotto editoriale ai sensi della legge n. 62/2001.