Donnerstag, 22. Dezember 2016

Systeminformationen sammeln um einen eindeutigen Daumenabdruck zu generieren / Collecting Systeminformation to generate a unique fingerprint

Wenn für unsere Applikation der Bedarf besteht, dass sie nicht unkontrolliert auf ein anderes System kopierbar sein soll, dann können wir mit Hilfe der WMI (Windows Management Instrumentation) diverse Informationen aus Windows herauskitzeln.
Im Folgenden werden wir eine ID basierend auf CPU, Netzwerkadaptern und Festplatten zusammenstellen. Bei den Festplatten erfolgt eine Beschränkung auf fest installierte Datenträger. D.h. keine RAM Disks, Netzlaufwerke, CD/DVD-ROMs, SD-Karten.

Der Mustercode geht von einer verbauten CPU, mehreren Netzwerkadaptern sowie mehreren Festplatten bzw. Partitionen.

Aus dem generierten String wird im Anschluß eine Checksumme gebildet.

Um gezielt auf den Wechsel/Wegfall/Einbau einzelner Komponenten reagieren zu können kann der im Beispiel konkatenierte String auch mit Hilfe von festen Blocklängen untergliedert werden so dass bei Änderung eines einzelnen Segmentes/Blocks nicht sofort Alarm geschlagen wird.

Im Echteinsatz sollten die mit '?' beginnenden Infoausgaben natürlich auskommentiert/entfernt werden :)

CLEAR 

LOCAL lcSystemID as String
lcSystemID = []

* // retrieve CPU ID
LOCAL    lcComputerName as String, loWMI as Object, ;
        lowmiWin32Objects as Object, lowmiWin32Object as Object
lcComputerName = GETWORDNUM( SYS( 0 ) , 1 )
loWMI = GETOBJECT( [WinMgmts://] + lcComputerName )
lowmiWin32Objects = loWMI.InstancesOf( [Win32_Processor] )
FOR EACH lowmiWin32Object IN lowmiWin32Objects
    WITH lowmiWin32Object
        ? [ProcessorId: ] + TRANSFORM( .ProcessorId )
        lcSystemID = TRANSFORM( .ProcessorId )
    ENDWITH
ENDFOR
?
RELEASE lcComputerName, loWMI, lowmiWin32Objects, lowmiWin32Object

* // retrieve the MAC Address(es)
* // usually more than one (BT,WLAN,LAN,VNA)
LOCAL    lcComputerName as String, loWMIService as Object, ;
        loItems as Object, loItem as Object, lcMACAddress as String
lcComputerName = [.]
loWMIService = GETOBJECT( [winmgmts:\\] + lcComputerName + [\root\cimv2] )
loItems = loWMIService.ExecQuery( [Select * from Win32_NetworkAdapter] , , 48 )
FOR EACH loItem IN loItems
    lcMACAddress = loItem.MACAddress
    IF !ISNULL( lcMACAddress )
        ? [MAC Address: ] + loItem.MACAddress
        lcSystemID = lcSystemID + CHRTRAN( loItem.MACAddress , [:] , [] )
    ENDIF
ENDFOR
?
RELEASE lcComputerName, loWMIService, loItems, loItem, lcMACAdress

* // retrieve Volume Serial Number(s)
* // maybe more than one, even HQ NBs often have SSD and HD
LOCAL    lcComputerName as String, loWMIService as Object, ;
        loItems as Object, loItem as Object, lcVolumeSerial as String
lcComputerName = [.]
loWMIService = GETOBJECT( [winmgmts:\\] + lcComputerName + [\root\cimv2] )
loItems = loWMIService.ExecQuery( [Select * from Win32_LogicalDisk] )

FOR EACH loItem IN loItems
    lcVolumeSerial = loItem.VolumeSerialNumber
    IF !ISNULL( lcVolumeSerial ) AND CheckDriveType4( loItem.DeviceID ) = .T.
        ? [DeviceID / VSN: ] + loItem.DeviceID
        ?? [ / ] + loItem.VolumeSerialNumber
        lcSystemID = lcSystemID + loItem.VolumeSerialNumber
    ENDIF
ENDFOR
?

? [SystemID Pure:] + PADL( TRANSFORM( LEN( lcSystemID ) ) , 4 , [ ] ) + [ Chars - ] 
?? lcSystemID
? [Prüfziffer:] + SYS( 2007 , lcSystemID , 1 , 1 )
?
lcSystemID = STRCONV( lcSystemID,13)
? [SystemID MIME:] + PADL( TRANSFORM( LEN( lcSystemID ) ) , 4 , [ ] ) + [ Chars - ] 
?? lcSystemID 
? [Prüfziffer:] + SYS( 2007 , lcSystemID , 1 , 1 )

RELEASE lcComputerName, loWMIService, loItems, loItem, lcVolumeSerial, lcSystemID

FUNCTION CheckDriveType4 as Boolean
LPARAMETERS vName as String

    * // Returnvalues of GetDriveType:    
    * // 0 = DRIVE_UNKNOWN                
    * // 1 = DRIVE_NO_ROOT_DIR            
    * // 2 = DRIVE_REMOVABLE            
    * // 3 = DRIVE_FIXED                
    * // 4 = DRIVE_REMOTE                
    * // 5 = DRIVE_CDROM                
    * // 6 = DRIVE_RAMDISK                
    vName = ADDBS( EVL( vName , [C:] ) )
    
    LOCAL llReturn as Boolean
    llReturn = .F.
    
    DECLARE INTEGER GetDriveType IN kernel32 String lpszRootPathName
    IF GetDriveType( vName ) = 3
        llReturn = .T.
    ENDIF 
    
    RETURN llReturn

ENDFUNC 

SystemID und Checksumme sollten an unterschiedlichen Stellen hinterlegt sein.

Dieser Ansatz ist sicherlich nicht 'bulletproof', aber der Aufwand hält sich in Grenzen und ist somit kostengünstig umzusetzen.

Mittwoch, 7. September 2016

Objekte einer Form zur Laufzeit duplizieren / duplicating form objects at runtime

Präambel
Während der Entwicklung stehen uns für Builder die Methoden 'ReadMethod' und 'WriteMethod' zur Verfügung. Über diese können wir vorhanden Code auslesen und auch in Methoden hinein schreiben.
Zur Laufzeit steht uns dies leider nicht zur Verfügung. Aus diesem Grund müssen wir gezielt eigene von den VFP Basisklassen abgeleitete Klassen auf unseren Forms verwenden, wenn wir tatsächlich beliebige Objekte mit individuellem Methodencode duplizieren wollen.

Da dies nun geklärt ist wenden wir uns den Möglichkeiten zu, die uns zur Laufzeit zur Verfügung stehen...

Zunächst einmal erfolgt das Duplizieren eines vorhanden Objekts auf Basis seiner Klasse. D.h. wir lesen die Klasse des Quellobjektes aus und erzeugen es im Zielcontainer auf Basis dieser Vorgabe. An dieser Stelle stehen uns nun automatisch alle in einer abgeleiteten Klasse individuell ausprogrammierten Methoden zur Verfügung. Alles was nun noch zugewiesen werden muss sind die Eigenschaften des Quellobjektes. Also werden in einer Schleife die vorhandenen Eigenschaften gelesen und zugewiesen.

Mit Hilfe der Funktion AMEMBERS() ist dies ohne weiteres machbar. Allerdings müssen wir noch dafür sorgen, dass die duplizierbaren Objekte auch auf eine Duplizieranforderung reagieren. Das Codemuster beruht auf der Annahme, dass jedes dieser Objekte innerhalb seiner RightClick Methode den Aufruf der Dupliziermethode hinterlegt hat.
Lautet der Name der Methode zum Duplizieren von Objekten bspw. 'Thisform.Copy', dann sähe der Rightclick Aufruf in etwa wie folgt aus:

Thisform.Copy(This)


Innerhalb dieser Methode wird dann folgender Code eingefügt:

LPARAMETERS vObj as Object
= AMEMBERS( gaPropArray , vObj , 1 )
WITH Thisform.container2 
    * // trying to create a same named object in the target container    
    * // in case there is already a so named object, the CATCH will fire
    TRY 
        .AddObject( vObj.Name , vObj.Class )
        FOR liLoop = 1 TO ALEN( gaPropArray , 1 )
            oNewObj = EVALUATE( [Thisform.container2.] + vObj.Name )
            IF gaPropArray( liLoop , 2 ) = [Property]
                * // Some Props are write protected, so just try to assign a new value
                TRY 
                    oNewObj.&gaPropArray( liLoop , 1 ) = vObj.&gaPropArray( liLoop , 1 )
                CATCH 
                ENDTRY 
            ENDIF         
        ENDFOR 
    CATCH 
        MESSAGEBOX([Object already exists!],0+16+0,[Can't copy object])
    ENDTRY     
ENDWITH 


Um dieses Codemuster allgemein gültig zu halten sollten unsere abgeleiteten Klassen nicht nur den Aufruf der Dupliziermethode kennen wie sie in diesem Beispiel im RightClick Ereignis hinterlegt ist. Sinnvoll ist es an dieser Stelle auch, wenn wir spezielle Eigenschaften anlegen, mit denen wir später bspw. Zielcontainer, abhängige parallel positionierte Objekte (Textbox und Label gleichzeitig duplizieren), Objektnamensvergabe und Dupliziererlaubnis steuern.

Donnerstag, 21. April 2016

PDFs über das olebrowser Control anzeigen / using the olebrowser control to display PDF files

Vor vielen Jahren stand ich vor der Aufgabe, eine PDF Datei innerhalb einer VFP Maske anzuzeigen. Gelöst habe ich dies über das Einbetten des olebrowser activeX Controls. Dieses Objekt bekam als Zielseite (über .Navigate ) einfach die anzuzeigende PDF Datei hinterlegt und fertig war die Laube.

Was passiert jedoch, wenn der Anwender auf die Idee kommt, die angezeigte Datei aus der VFP Anwendung heraus zu löschen? GENAU....es poppt eine Fehlermeldung auf, dass die Datei von einer anderen Applikation gesperrt wird....

Grund ist, dass das ole Control und der darin instanziierte PDF Reader die Datei zu diesem Zeitpunkt noch anzeigen und somit diese auch sperren, was das Löschen derselbigen unmöglich macht.

Um die Datei wieder frei zu bekommen genügt es leider nicht, dem Browser Control als neue anzuzeigende Seite "about:blank" zuzuweisen. Bis das Control hinter sich aufgeräumt hat, sprich der PDF Reader geschlossen wurde, dauert es leider ein paar Millisekunden. Ein einfaches WAIT WINDOW mit timeout und anschliessendem Löschen ist keine Option, denn je nach Systemauslastung ist die Aktion in kürzerer oder in längerer Zeit durchlaufen. Um auf Nummer sicher zu gehen muss eine Warteschleife mit Abprüfung der Control Eigenschaft '.ReadyState' her.

https://msdn.microsoft.com/en-us/library/bb268229%28v=vs.85%29.aspx

Wie im obigen Link nachzulesen ist, verfügt diese Eigenschaft über fünf Zustände

    READYSTATE_UNINITIALIZED = 0
    READYSTATE_LOADING = 1
    READYSTATE_LOADED = 2
    READYSTATE_INTERACTIVE = 3
    READYSTATE_COMPLETE = 4

von denen uns an dieser Stelle nur READYSTATE_COMPLETE = 4 interessiert.

Hier nun das notwendige Codesnippet:

?DeleteFileInBrowser( [c:\temp\myFile.pdf] )

FUNCTION DeleteFileInBrowser as Boolean
LPARAMETERS vFile as String

    LOCAL llReturn as Boolean
    llReturn = .F.
    
    IF FILE( vFile )

        DECLARE Sleep IN WIN32API INTEGER

        oBrowser = Thisform.oleBrowser
        oBrowser.Navigate( [about:blank] )
        DO WHILE oBrowser.ReadyState <> 4
                Sleep(200)                
        ENDDO 

        TRY 
            DELETE FILE ( vFile )
            llReturn = .T.
        CATCH 
            * Something went wrong
            * llReturn stays .F.
        ENDTRY 
        
    ENDIF 

    RETURN llReturn
    
ENDFUNC