Deutsch
Forum

Erledigt: Statische Funktionen in Includes

 
- Seite 1 -



Nico
Madysa
Hallo iF!

Ich habe in meinem Hauptprogramm einige APIs mittels ImportDLL() importiert, und zwar nach folgendem Muster
KompilierenMarkierenSeparieren
var hUser& = ImportDLL(USER32,u_)
var hKern& = ImportDLL(KERNEL32,k_)
var hGDI&  = ImportDLL(GDI32,g_)
var hPros& = ImportDLL(prospeed,)

Dem angeschlossen sind einige Includedateien, von denen eine, eigens für dieses Programm erstellte auf eben diese Funktionen zurückgreift, bspw. mit
KompilierenMarkierenSeparieren
Nun zwingen mich einige besondere Umstände dazu, XPSE zu nutzen, welches jedoch jedesmal aufs Neue behauptet, ihm sei die Funktion u_GetWindowRect() in XYZ.INC unbekannt.

Nochmals will ich darauf hinweisen, daß diese Prozedur maßgeschneidert für dieses Programm ist und ich somit auch auf Dinge, welche erst im Hauptprogramm definiert werden zugreifen können will. Bisher zwingt mich diese Fehlermeldung dazu, ständig {$noerr} zu verwenden, wodurch allerdings natürlich auch alle echten Fehler ignoriert werden, was mir ebenfalls mißfällt.

Meine Frage nun: Ist eine solche Kapselung von Includedateien wirklich nötig oder könnte XPSE nicht einfach gnädiger sein?
 
Nico Madysa
24.03.2009  
 



 
- Seite 1 -



Nico
Madysa
iF
@Nico: Die NOERR-Keule kann für Einzelfälle von pushKeyWord verhindert werden


Haha, ich wußte doch, daß es da noch etwas für den Einzelfall gab - nur, daß ich vergessen hatte, daß das Ding PushKeyWord hieß - danke!

iF
Alternativ könnte ich ein Vorzeichen für Funktionen erfinden welche nicht angewarnt werden sollen, sowas wie __.


Und wie wärs, wenn du einfach ausläsest, welches Präfix in ImportFunc/ImportDLL angegeben wird und alle Funktionen mit den ausgelesenen Präfixen ignoriertest? Das klappte dann in meinem obigen Beispiele ja mit alles DLLs bis auf die Prospeed - dann müßten XPSE-Nutzer halt bei Import-x() ein Präfix angeben, eine Einschränkung, an welche sogar ich mich gewöhnen könnte.
 
Nico Madysa
25.03.2009  
 



Es nennt sich Tilde.

Für mich ist ein Ding...
Natürlich hatte ich schon voller Erwartung auf die Belehrung gewartét.

Hatte zu Hause mit einem Kameraden darüber schon eine Wette abgeschlossen.
Also, ihr seid schon richtig lustig, bei euch bleibe ich
Ist ein Forum voller Witz.

mfg
 
25.03.2009  
 




Matthias
Arlt
Gratuliere zur gewonnenen Wette
 
WinXP SP2, Win7 - XProfan 10/11/FreeProfan32 - Xpia
25.03.2009  
 



@Nico: So ähnlich mache ich das bei den Units, nur das ich dort auch noch vergleiche ob die Funktionen aus der .def-Datei übereinstimmen und mit dem Unterschied das dass Präfix nicht in einer Stringkonstante abgelegt* wird. Das sollte aber hinzubekommen sein wenn das Präfix auf einen . (in Worten: Punkt) endet.

Finde ich sowieso irgendwie komisch (aber dennoch auch wiederum verständlich) das Roland das Präfix bei import... in einem String erwartet.
 
25.03.2009  
 




RGH
iF
@Nico: So ähnlich mache ich das bei den Units, nur das ich dort auch noch vergleiche ob die Funktionen aus der .def-Datei übereinstimmen und mit dem Unterschied das dass Präfix nicht in einer Stringkonstante abgelegt* wird. Das sollte aber hinzubekommen sein wenn das Präfix auf einen . (in Worten: Punkt) endet.

Finde ich sowieso irgendwie komisch (aber dennoch auch wiederum verständlich) das Roland das Präfix bei import... in einem String erwartet.


Das Präfix ist nun mal eine Zeichenkette, also ein String.

Ich würde allerdings nicht den Punkt vorschreiben (ja nicht einmal empfehlen). Der Unterstrich wäre für diesen speziellen Fall die erste Wahl. Der Punkt trennt Objekt von Methode/Eigenschaft bzw. Klasse von Methode Eigenschaft und hat somit in der XProfan-Syntax eine definierte Bedeutung.
Noch erlaube ich in Bezeichnern nahezu alle Zeichen, aber ich habe schon des öfteren darüber nachgedacht, Bezeichner auf Buchstaben (A..Z,a..z), Ziffern (0..9) und Unterstriche (_) zu beschränken, wobei das erste Zeichen ein Buchstabe oder Unterstrich sein muss. Die Sorge um die Herzkranzgefässe einiger altgedienter User, die es bislang anders hielten, hat mich bisher davon abgehalten. ;)

Gruß
Roland
 
Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4
25.03.2009  
 



Auch wenn z.B. ich nicht immer eine Klasse definiere - so einklassiere (ich wollte nicht klassifizieren schreiben ) ich dennoch fast alles nach dieser Syntax - der Übersicht wegen behaupte ich einfach es sind alles Klassen!

Ein Beispiel:

ogl.clear
ogl.push
ogl.pop

gehört alles zu ogl - wie ich finde sehr praktisch und das ziehe ich seither auch in grösseren Programmen so durch.

Man könnte also sagen, ogl sei hier nach der Syntax eine klasse - wenn auch keine echte.

Und wenn man z.B. aus einer klasse DLL alle Funktionen einholt, dann liegt es doch garnicht fern zu sagen: thisDll.methode

Das es nicht ganz korrekt ist, ist mir klar - hingegen XProfan jedoch nicht Objektbezogen arbeitet wie z.B.

declare a$,b$
b$=a$.mid$(1,10)

womit das meinige Prinzip insich wiederum schlüssig ist und im Alltag breite praktischste Verwendung gefunden hat.

Das wiederum Praktische ist dass keiner (speziell) meiner Wünsche Dich an irgendwas (wie z.B. die Abschaffung des Punktes aus den Bezeichnernamen) hindern müssen da ich mir das XProfan per XPSE ja auf meine Bedürfnisse zurechtrücke.
 
25.03.2009  
 



 
- Seite 2 -


...Versuch einer Übersetzung des letzten Beitrags ins Deutsche:

Auch wenn nicht immer eine Klasse definiert wird, richte ich persönlich fast alles nach dieser Syntax aus. Beispiele:

ogl.clear
ogl.push
ogl.pop

Hier gehört alles zur (Pseudo-)Klasse ogl. Ich finde das praktisch und wende das in allen größeren Programmen an.

Wenn man aus einer klasse DLL (Ist das ein Witz?, Anm.d.Ü.) alle Funktionen einholt (einholt ist wirklich schwer zu übersetzen, vermutlich meint der Autor extrahiert, Anm.d.Ü.), dann liegt es meines Erachtens nahe, dafür thisDll.method zu schreiben.

Dass das im Sinne der Profan-Syntax nicht ganz korrekt ist, ist klar - XProfan arbeitet ja auch nicht konsequent Objekt-bezogen, da sonst folgendes Beispiel funktionieren müsste:

declare a$,b$
b$=a$.mid$(1,10)

Meine Vorgangsweise hat zumindest den Vorteil, in sich schlüssig zu sein, und hat deshalb (wie oben erwähnt) in meinem Arbeitsalltag inzwischen breite praktische Verwendung gefunden.

Natürlich soll das niemanden in der Syntax einschränken, etwa wenn jemand den Punkt aus seinen Bezeichnern generell verbannen will. XPSE wird jedenfalls beide Bezeichnersysteme unterstützen.

+++

Liebe Redaktion, stimmt das so?
 
26.03.2009  
 



Prima!

Ich sollte Dich mir unbedingt für einen Posten vorschlagen!

Redaktion find ich gut! Bist Du unser Redakteur?
 
26.03.2009  
 



Liebe Redaktion, stimmt das so?

jaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa..........
 
26.03.2009  
 



@Nico: In der kommenden Version wirst Du z.B. per
KompilierenMarkierenSeparieren
 {$pushkeyword u_*}
festlegen können, dass alle Funktionsaufrufe welche mit u_ beginnen, nicht angewarnt werden. Man kann somit auch z.B. per
KompilierenMarkierenSeparieren
 {$pushkeyword _*}
alle Funktionen unangewarnt deklarieren, welche mit _ beginnen.
 
11.04.2009  
 




Nico
Madysa
Das kommt mir entgegen, danke!
 
Nico Madysa
17.04.2009  
 



Ist bereits eingebaut, viel Spass.
 
17.04.2009  
 




Antworten


Thementitel, max. 100 Zeichen.
 

Systemprofile:

Kein Systemprofil angelegt. [anlegen]

XProfan:

 Beitrag  Schrift  Smilies  ▼ 

Bitte anmelden um einen Beitrag zu verfassen.
 

Themenoptionen

12.439 Betrachtungen

Unbenanntvor 0 min.
Ernst07.05.2016
p.specht21.12.2013
E.T.17.01.2012
Roland Schäffer05.02.2011

Themeninformationen



Admins  |  AGB  |  Anwendungen  |  Autoren  |  Chat  |  Datenschutz  |  Download  |  Eingangshalle  |  Hilfe  |  Händlerportal  |  Impressum  |  Mart  |  Schnittstellen  |  SDK  |  Services  |  Spiele  |  Suche  |  Support

Ein Projekt aller XProfaner, die es gibt!


Mein XProfan
Private Nachrichten
Eigenes Ablageforum
Themen-Merkliste
Eigene Beiträge
Eigene Themen
Zwischenablage
Abmelden
 Deutsch English Français Español Italia
Übersetzungen

Datenschutz


Wir verwenden Cookies nur als Session-Cookies wegen der technischen Notwendigkeit und bei uns gibt es keine Cookies von Drittanbietern.

Wenn du hier auf unsere Webseite klickst oder navigierst, stimmst du unserer Erfassung von Informationen in unseren Cookies auf XProfan.Net zu.

Weitere Informationen zu unseren Cookies und dazu, wie du die Kontrolle darüber behältst, findest du in unserer nachfolgenden Datenschutzerklärung.


einverstandenDatenschutzerklärung
Ich möchte keinen Cookie