Dynamische Variablen in Delphi ???

[lhmultimedia]

Hi Leute.
Gibt es in Delphi sowas wie in PHP Das doppelte Dollarzeichen bei den Variablen, hier ein Beispiel:

Code:

<?php
$a = "b";
$b = "Hallo";
echo $$a;
?>

Hierbei steht in Variable a der Name von Variable b.
Durch echo $$a wird also Nicht der Buchstabe b ausgegeben, sondern der Inhalt von Variable b (wegen des doppelten Dollarzeichens).
Kann man sowas in delphi auch realisieren?

[alzaimar]

Zeigervariablen.

[lhmultimedia]

Und wie macht man dann sowas?

[Corpsman]

du meinst in etwa so was ??

Delphi-Quellcode:

var a:Pointer;
    b:String;
begin
  b := 'Hallo Welt';
  a := @b[1];
  showmessage(pchar(a));

Aber in meinen Augen ist das totaler Schwachsinn.

[lhmultimedia]

Danke.
Veträgt sich Pointer auch mit StringList (damit man Mehrere Pointer als String speichern kann)?

[Nuclear-Ping]

TList in dem Falle.

[lhmultimedia]

Kann man einen String in einen Pointer umwandeln?

[Der_Unwissende]

Hi,

ich glaube die eigentlich interessante Frage ist, wofür genau Du diese "Funktion" nutzen möchtest. Nicht umsonst sagt Corpman, dass es totaler Schwachsinn sei, so zu arbeiten.
An sich sind Pointer natürlich eine Möglichkeit, die dem von Dir beschriebenen Verhalten ähneln, allerdings (und darauf spielst Du wohl schon mit der TStringlist an) handelt es sich nicht um eine Zuordnung von Bezeichner zu Pointer. Sicherlich kannst Du eine TStringList ordentlich missbrauchen und da (leider) sogar Pointer ablegen, aber die Frage ist, ob das Sinn der Sache sein sollte.

Während Skriptsprachen gerne mit ihrer hohen Flexibilität (man muss ja nicht mal den Datentypen festlegen) aufwarten, liegt hier auch ein immenser Nachteil dieser Sprachen. Ohne einen bekannten Typ geht hier einfach mal die Typsicherheit verloren, eine nicht unwichtige Eigenschaft moderner Sprachen. Viele Fehler können einfach vermieden werden, wenn eine Überprüfung schon zur Übersetzungszeit eine unerwünschtes Verhalten ergibt. Bei vermeidbaren Problemen ist (imho) die Arbeit mit untypisierten Pointern ziemlich weit vorne bei (kommt eben drauf an ob man sie wirklich benötigt).

Wenn Du einfach nur Zeiger unter einem bestimmten Namen ablegen möchtest (und natürlich auch wieder zugreifen), dann ist eine Map bzw. ein Dictionary das was Du suchst. In Delphi gibt es da keine all zu ausgereiften Varianten, Du findest aber schnell welche wenn Du in der DP suchst. Alzaimar hat mal eine Dictionary - Klasse gepostet, die ordentlich in der Perfomance ist und all das leistet, was Du gerne hättest.

Gruß,
Der Unwissende

[Der_Unwissende]

Zitat:

Zitat von lhmultimedia

Kann man einen String in einen Pointer umwandeln?

Äh, was willst Du denn da rausbekommen? Ich meine das was Du eigentlich wissen willst geht, aber die Frage ist echt ungeschickt formuliert. So kann man natürlich ein Float in ein Integer umwandelt (es geht eben ein Datenverlust einher), ein Byte kann man auch leicht in Integer umwandeln (wird eben mit Nullen aufgefüllt) oder in ein Char.
Einen String kann man also sicher auch in einen Pointer umwandeln, aber das dürfte wenig Sinn machen.

Für Dich dürfte ein Pointer auf den Inhalt des Strings deutlich interessanter sein. Nimmst Du hier nur die Adresse des Strings, so hast Du ein Problem, der String wird einfach freigegeben (da Delphi den selbst verwaltet). Deshalb musst Du dafür sorgen, dass Du einen Zeiger auf einen Speicherbereich bekommst, bei dem Du Dich um die Freigabe kümmerst. Dazu kannst Du entsprechend einfach Speicher reservieren (gibt da rund um PChar afaik ein paar Funktionen) und Du kannst so einen Zeiger erzeugen, der auf ein PChar (Nullterminierte Zeichenkette) zeigt oder in dem Du die Zeichen ablegst (wo Du Dich dann aber auch um die Längeninformation kümmern musst).

[Nuclear-Ping]

Ja, wäre auch mal interessant zu wissen, was er überhaupt vor hat. :mrgreen:

[1234588]

Zitat:

Zitat von Der_Unwissende

Nicht umsonst sagt Corpman, dass es totaler Schwachsinn sei, so zu arbeiten.

ich halte es nicht fuer schwachsinnig. was allerdings sehr schwachsinnig ist, ist wenn man unnoetig castet. das ist genauso sinnvoll wie ein pointer, der auf einen pointer zeigt.

[lhmultimedia]

Ich hab die frage falsch formuliert (sorry dass es mir erst jetzt aufgefallen ist), jedenfalls hat delphi gemotzt weil pointer und string sich nicht vertragen (als ich versucht habe dem String auf den der Pinter zeigt Text hinzuzufügen), ich hab mir aber den quellcode noch mal angeschaut und herausgefunden dass die Problemlösung PChar heißt! (ich hatte vor dem String auf den der Pointer zeigt TExt hinzuzufügen) :wall: :wall: :wall:
Vielen Dank für die Hilfe.

[lhmultimedia]

Was kann ich machen wenn ich damit eine Caption auslesen will.
Das heißt der Benutzer Schreibt z.b in Edit1 "Button1.Caption".
Angenommen b ist also jetzt "Button1.Caption", wie kann ich dies per Pointer darstellen???

[1234588]

das geht in delphi nicht ohne weiteres

if edit1.text = 'Button1.Caption' then miep


//edit
mit FindComponent usw. muesste sowas doch funtkionieren?

[vsilverlord]

Delphi-Quellcode:

while i<componentcount-1 do
begin
     if components[i] is tedit then
       begin
       if components[i].caption='noob' then meeep
       end
i:=i+1
end

(ungetestet) sollte funktionieren. :stupid:
aber warum der unsinn wenns auch einfach geht

[lhmultimedia]

Zitat:

Zitat von vsilverlord

Delphi-Quellcode:

while i<componentcount-1 do
...
i:=i+1

1. würde es ne for schleife nicht auch tun

Zitat:

Zitat von vsilverlord

Delphi-Quellcode:

...
     if components[i] is ->->->tedit<-<-<- then
     ...

2. hier wird nach der caption von einem über edit festgelegten element gefragt nicht nach der Edit oder deren Caption selbst!!!

[Der_Unwissende]

Zitat:

Zitat von lhmultimedia

2. hier wird nach der caption von einem über edit festgelegten element gefragt nicht nach der Edit oder deren Caption selbst!!!

Muss man diese Aussage verstehen?
Wie aber schon gesagt wurde gibt es eine Funktion, die direkt nach einem Control mit angegebenem Namen sucht (findChildControl oder so). Controls bietet sich nebenbei als Eigenschaft eher an als Components, da es sich um eine echte Teilmenge handelt. Alles was visuell ist, tausch sowohl als Component, aber eben auch in Controls auf. Die nicht sichtbaren Komponenten landen hingegen nur in der Components - Eigenschaft.

Aber es stellt sich eben (erneut) die Frage, wo Du eigentlich hin möchtest. Gibt halt verschiedene Ansätze um an die Caption zu kommen, welcher am geschicktesten ist oder wo eben die Grenzen einer Möglichkeit liegen lässt sich aber nun mal leichter bestimmen, wenn man das Ziel kennt...

[Nuclear-Ping]

Was hast du denn überhaupt vor?

[vsilverlord]

Ich glaube er will was, was ich auch schon lange will, wofür es aber leider keine Möglichkeit in Delphi gibt.
Also ich glaube er will im Debuggten Programm Programmierbefehle geben, also z.b wenn er ins edit 'form1.color:=clblue' schreibt, dass dann das Fenster blau wird, oder Eigenschaften von Objekten abfragen. Die einzige Möglichkeit, die ich sehe, ist dass man da jedes kleine Ding mit if einprogrammieren muss, also if edit1.text ='...' then meep

[mkinzler]

Dann verwende doch eine Pascalskripting-Komponente.

[lhmultimedia]

@vsilverlord Falsch habe ich nicht vor.
Ich habe vor in eine Datei Namen von Strings zu schreiben.
Dann wird im Programm die Sprachdatei angegeben und die jeweiligen Strings werden durch die strings in der 2. Datei ersetzt.

[mkinzler]

Auch dafür gibt es schon viele Lösungen. Je nach Delphi Version auch ohne Fremdsooftware/Komponenten

[lhmultimedia]

Tja mach ich halt auch mal ne "Lösung".
(Weis zufällig jemand in welcher Unit ShowMessage steht???)

[DeddyH]

Dialogs

[Nuclear-Ping]

Zitat:

Zitat von lhmultimedia

@vsilverlord Falsch habe ich nicht vor.
Ich habe vor in eine Datei Namen von Strings zu schreiben.
Dann wird im Programm die Sprachdatei angegeben und die jeweiligen Strings werden durch die strings in der 2. Datei ersetzt.

Warum machst du das zB nicht über Ressourcen?

Code:

// german.rc
STRINGTABLE {
         1, "Deutsch"
         2, "Datei"
         3, "Öffnen"
         4, "Speichern"
         ...
}

Dann per brcc32 in eine .res-Datei compilen, die du zB in eine german.dll einbindest, die du dann im Programm per LoadLibrary lädst und dann auf die Ressourcen zugreifst?

Delphi-Quellcode:

// ID = Index aus StringTable der .rc Datei
// LangLibHnd = Handle der DLL, Rückgabewert von LoadLibrary
function TLanguageClass.GetString (ID: Integer; LangLibHnd: Integer = -1): String;
var
        ResPtr: PChar;
        LangHnd,
        ResLen: Integer;
begin
        ResLen := 1024000;
        if LangLibHnd = -1 then
                LangHnd := FLangHandle
        else                          
                LangHnd := LangLibHnd;
        GetMem (ResPtr, ResLen);
        try
                if LoadString (LangHnd, ID, ResPtr, ResLen) = 0 then
                        Result := '? ' + inttostr (ID) + ' ?'
                else Result := StrPas (ResPtr);
        finally
                FreeMem (ResPtr);
        end;
end;

Delphi-Quellcode:

ShowMessage (Language.GetString(3)); // Öffnen

[lhmultimedia]

:gruebel: :gruebel: :shock: :shock: :wiejetzt:
Naja. Ich werds wahrscheinlich eh nicht so machen! :roll:

[mkinzler]

Und warum?

[lhmultimedia]

Ich werde da wahrscheinlich eine Komponente schreiben (und wahrscheinlich auch online stellen) und daher ist es ein bisschen zu umständlich wenn der Benutzer (also der Programmierer) im Endeffekt für jede Sprachdatei ne dll machen müsste, oder?

[mkinzler]

Und warum sollte man deine Lösung wählen, da es schon viele Lösungen gibt?

[lhmultimedia]

Aus Mitleid zu mir noob ^^ nee scherz, keine Ahnung :mrgreen: :mrgreen: :mrgreen:

[Nuclear-Ping]

Zitat:

Zitat von lhmultimedia

daher ist es ein bisschen zu umständlich wenn der Benutzer (also der Programmierer) im Endeffekt für jede Sprachdatei ne dll machen müsste, oder?

Ist aber die gängige Methode. Oder du nimmst Text- / Ini-Dateien. Kommt unter'm Strich aber auf's gleiche raus, nur dass die jeweiligen Texte aus einer anderen Quelle stammen. Auch ist da der Schutz höher, wenn du Texte im Programm hast, die nicht einfach so durch den Benutzer geändert werden dürfen (Disclaimer, Copyright-Hinweise, ...).

Wir habens so gemacht:
- Sprachen werden als .rc "entwickelt" / abgelegt
- Übersetzer erhalten ein selbstentwickeltest Tool, womit sie diese Ressourcen einfach übersetzen können (tabellarische Ansicht, links die Ausgangs-, rechts die Zielsprache, ...)
- Das Tool lädt automatisch bearbeitete Ressourcen auf einen FTP
- Da zieh ich sie mir runter, compile sie und packe einfach ne weitere DLL in's Sprach-Verzeichnis, ohne irgendwas am Code ändern zu müssen
- Fertig

[lhmultimedia]

Zitat:

Zitat von Nuclear-Ping

...(Disclaimer, Copyright-Hinweise) ...

Ja, das ist verständlich.
Mal sehen, ob ich eine Verschlüsselung einbaue!