Ciao Vladimiro,
Visto i commenti di Daniele in relazione alla mia funzione LastRow, vorrei offire i seguenti chiarimenti:
La versione generica della funzione è:
'=========>>
Public Function LastRow(SH As Worksheet, _
Optional Rng As Range, _
Optional minRow As Long = 1, _
Optional sPassword As String)
Dim bProtected As Boolean
With SH
If Rng Is Nothing Then
Set Rng = .Cells
End If
bProtected = .ProtectContents = True
If bProtected Then
.Unprotect Password:=sPassword
End If
End With
On Error Resume Next
LastRow = Rng.Find(What:="*", _
After:=Rng.Cells(1), _
Lookat:=xlPart, _
LookIn:=xlFormulas, _
SearchOrder:=xlByRows, _
SearchDirection:=xlPrevious, _
MatchCase:=False).Row
On Error GoTo 0
If LastRow < minRow Then
LastRow = minRow
End If
If bProtected Then
SH.Protect Password:=sPassword
End If
End Function
'<<=========
- La lunghezza della funzione ha ben poco da fare con la sua efficienza o la velocità di esecuzione; un codice lungo può essere molto più veloce di un'istruzione di una sola riga. Detto questo, la verbosità del codice non necessaria dovrebbe essere evitata
:-) A questo proposito, il tempo di esecuzione della funzione e piccolissimo. Utilizzando il mio computer più vecchio (più di 10 anni e con pochissima memoria) il tempo di esecuzione per 100 chiamate alla funzione è stato misurato in centesimi di secondo.
Puoi verificarlo con la seguente semplice procedura:
'=========>>
Public Sub Tester()
Dim i As Long
Dim dStart As Double, elapsedTime as double
dStart = Timer
For i = 1 To 100
Call LastRow(ActiveSheet)
Next i
elapsedTime = Timer - dStart
Call MsgBox( _
Prompt:=elapsedTime, _
Buttons:=vbInformation, _
Title:="TEMPO DI ESECUZIONE")
End Sub
'<<=========

- L'uso del codice proposto da Daniel è soggetto ad alcune limitazioni che di solito sono sufficienti per dissuadermi dal suo uso. Ad esempio, il codice di Daniel ignorerà le righe nascoste nella parte inferiore dei dati e poiché restituirà solo informazioni
per la colonna specificata, non può essere utilizzato in modo affidabile per trovare l'ultima
riga popolata
- Poiché quasi tutti i miei progetti di codice richiedono la definizione della prima riga vuota, è conveniente per me includere la mia funzione nella mia Personal.xlsb anziché dover riscrivere le istruzioni ogni volta.
- In conclusione, Daniel suggerisce che non è corretto dichiarare nomi di variabili in lettere maiuscole. Non sono d'accordo: il suggerimento di Daniel rappresenta solo una convenzione adottata da alcuni programmatori; ci sono altre convenzioni e, secondo
la mia modesta opinione, i fattori decisivi in qualsiasi convenzione di denominazione dovrebbero essere chiarezza e coerenza. A questo proposito, potrebbe essere interessante vedere i commenti di Chip Pearson:
Many programmers prefer to use what is called Hungarian Notation (so
named because the originator of this method was Hungarian-born Charles Simonyi, first at Xerox PARC and later a top level software architect at Microsoft). In Hungarian Notation, every variable name begins with letters that identify the data type. For example,
anInteger type variable would be named intCounter,
where the int prefix indicates that this is an Integertype.
I have never adopted Hungarian Notation in straight VBA code, but I always use it when naming controls on a form. If you like the idea behind Hungarian Notation, I encourage you to use it. Just be consistent -- once you decide on a set of identifier prefixes,
use them consistently in all your code.
Personalmente, utilizzo invariabilmente lettere maiuscole per una variabile che rappresenta una cartella di lavoro o un foglio e non vedo alcun motivo per cambiare la mia pratica.
Nulla di ciò che ho scritto dovrebbe essere interpretato come una polemica: è perfettamente possibile che la gente abbia opinioni diverse e io ho semplicemente voluto ristabilire l'equilibrio.
===
Regards,
Norman
