Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
ejomi
Anmeldungsdatum: 21.03.2006 Beiträge: 4
|
Verfasst am: 21.03.2006, 12:55 Titel: RESTORE-Label als Variable? |
|
|
Kann man DATA-Labels mit RESTORE irgendwie variabel anpringen?
Also sinngemäß (der folgende Code funktioniert natürlich nicht):
Code: | LabelVar$="d1"
RESTORE LabelVar$
READ x: [und jetzt tu' was mit 'x']
END
d1: DATA a
d2: DATA b
d3: DATA c |
wobei ich dann nur durch Ändern des Variablen-Inhalts von LabelVar$ z.B. in "d2" das Sprungziel "d2" erreichen würde? Ich würde mich über einen Tip sehr freuen (oder geht das ganze aus prinzipiellen Gründen überhaupt nicht??).
Gruß: ejomi |
|
Nach oben |
|
|
gripslund
Anmeldungsdatum: 09.03.2006 Beiträge: 10 Wohnort: Quesitz
|
Verfasst am: 23.03.2006, 23:38 Titel: |
|
|
Hallo ejomi,
also für QB kenne ich leider keine Lösung. Aber es gibt Interpreter die sowas bringen. Ich hab' 'nen CASIO FX-880P und da funktioniert das wunderbar:
Bsp. wenn DPW = 4
510 RESTORE (900+DPW)
...
901 DATA ...
902 DATA ...
903 DATA ...
904 DATA ...
905 DATA ...
-> es werden die Daten aus Zeile 904 gelesen.
Ist doch was Du meinst, oder? Aber wie schon oben gesagt leider nicht in QB. Ich habe alles mit IF ... THEN RESTORE ... umschrieben, was nat. nicht schön aussieht und viel Arbeit macht. Eine andere Lösung kenne ich nicht (evtl. CASE SELECT noch). Sorry.
gripslund |
|
Nach oben |
|
|
ejomi
Anmeldungsdatum: 21.03.2006 Beiträge: 4
|
Verfasst am: 24.03.2006, 08:22 Titel: exakt das wär's gewesen! |
|
|
Danke erst mal "gripslund"! Das, was CASIO macht, wäre genau mein Fall gewesen. Hat denn vielleicht sonst jemand eine Idee, wie man so etwas unter QB hinbekommen kann? Die von gripslund vorgeschlagene Methode mit CASE-SELECT setzt ja wiederum nur festgelegte Spungziele vorraus (ist also statisch) und würde bei einer - in meinem Fall x-Zeilen - langen DATA-Liste eine ebenso lange CASE-Liste voraussetzen. Da kann ich doch lieber gleich mit RESTORE im Code weiter machen! Aber genau das möchte ich ja nicht: kein statisches Vorgehen, keine langen Code-Listen! (Huch - das war jetzt 'ne doppelte Verneinung - aber ihr wisst was ich meine!).
Also - sollte da unter QB wirklich keine Lösung in Sicht sein?? Was sagen denn die Assembler-Spezis zu dem Problem?? ... die Jungs haben doch sonst immer die fetzigsten Tricks auf Lager, für scheinbar unmögliches: schwupp, nur ein paar Maschinen-Befehle und mein PC kann plötzlich Liedchen singen ... und da hätte keiner 'ne Idee, wie man so ein paar alberne DATA-Zeilen in den Griff bekommt, gibt's doch garnicht!??
Herzl. Grüße aus Dresden vom frustrierten ejomi |
|
Nach oben |
|
|
Stormy
Anmeldungsdatum: 10.09.2004 Beiträge: 567 Wohnort: Sachsen - wo die schönen Frauen wachsen ;)
|
|
Nach oben |
|
|
ejomi
Anmeldungsdatum: 21.03.2006 Beiträge: 4
|
Verfasst am: 24.03.2006, 10:59 Titel: Hmm - Datei ist eben nicht DATA! |
|
|
Erst mal: Danke "stormy". Nun - mit externen Dateien kann man natürlich alles lösen! Damit bewegen wir uns aber dann in Richtung Programm-Stückelung, wie wir sie ja z.B. von unserem allseits lieb-gewonnenen Betriebssystem aus dem fernen Redmond, USA nun wirklich zu Genüge kennen! Bei einem kleinen Hilfs-Progrämmchen, das ich mir unter QB zusammenflicke, sollte es aber eben möglichst nicht dazu kommen: man könnte mich am Ende mit einem bekannten Software-Magnaten aus Amerika verwechseln - soweit will ich es natürlich nicht kommen lassen!
An dieser Stelle möchte ich mal einen Seufzer an alle DLL-Freaks los werden: so schön diese Idee auch ist - sie sorgt genau für das oben beschriebene Problem! Fakt ist, dass sowieso die meisten für sich das Rad immer wieder neu erfinden und deshalb 90% aller angeblich gemeinsam genutzten DLLs in den Verzeichnisse der Platte vor sich hin schimmeln. Da muss man sich dann beim Deinstallieren des betreffenden Programms auch noch die Frage gefallen lassen, ob man diese oder jene DLL wirklich löschen möchte, da diese ja vielleicht noch von anderen ... - herrjeh - welcher Laie soll denn das entscheiden? ... also wird sie vorsichtigerweise nicht gelöscht und am Ende ist die Festplatte (die mir gehört und bei der ich für jedes Byte Speicher bezahlt habe!) mit Daten-Müll von fremden Leuten vollgestopft - na, Dankeschön auch!
Es ist, als ob ich beim Kauf eines neuen Autos direkt eine ganzen Schrank Universal-Werkzeug (auch für andere Autos brauchbar) mitgeliefert bekäme. Beim Verschrotten des Autos hätte ich natürlich Hemmungen, diese schönen "Unversal-Werkzeuge" ebenfalls wegzuwerfen. Beim nächsten Kauf eines Autos bekäme ich aber wieder so einen Schrank mitgeliefert usw. - spätestens nach dem 3. Auto müsste ich mir dann eine 2. Garage anmieten, weil ich keinen Platz für meine tolle Werkzeugsammlung übrig habe - was mach ich dann? Ich brenn' die Hütte ab und kauf mir ein Auto aus Schweden ( = formatiere die Festplatte und wechsle das Betriebssystem!) - eines Tages bemerke ich dann, daß meine Garage schon wieder voll geworden ist ...
So - das gehörte jetzt zwar nicht zum Thema - aber ich wollte es mal los werden (ändern wird sich sowieso dadurch nix - aber es erleichtert)!
Vielleicht noch so viel: manch' ein Programmierer könnte sich diese Zeilen mal zu Herzen nehmen und versuchen sein Programm "autark" zu gestalten - dann gäb's zukünftig vielleicht weniger Installations- und Update-Probleme!
Soo - und was mach ich nun mit meinen DATA's ?
Nette Grüße aus Dresden, von einem er es gar nicht so ernst meint: ejomi ! |
|
Nach oben |
|
|
jb
Anmeldungsdatum: 14.01.2005 Beiträge: 2010
|
Verfasst am: 24.03.2006, 15:54 Titel: |
|
|
Eine Möglichkeit wäre doch sicher, es so zu machen:
Code: |
INPUT "Wohin gehen? ", bla$
SELECT CASE LCASE$(bla$)
CASE "haus"
RESTORE HAUS
CASE "wohnung"
RESTORE WOHNUNG
CASE ELSE
RESTORE FALSCH
END SELECT
HAUS:
' [...]
WOHNUNG:
' [...]
FALSCH:
' [...]
|
Ist zwar auch nicht so das gelbe vom Ei, aber immerhin...
jb _________________ Elektronik und Programmieren |
|
Nach oben |
|
|
Michael Frey
Anmeldungsdatum: 18.12.2004 Beiträge: 2577 Wohnort: Schweiz
|
Verfasst am: 24.03.2006, 19:17 Titel: |
|
|
Man könnte die Zweite Datei (also die Textdatei) einfach Huckepack auf die Exe Datei aufsetzen.
Also etwas deutlicher:
Wenn das Programm 2000 Byte gross ist, hängst du ab 3000 Byte einfach die Textdatei an.
Nachher öffnet sich das Programm selbst und verschiebt die Adresse (dem Punkt ab dem es liesst) auf 3000 Byte, dann kannst du die Daten ganz Normal einlessen als wären sie in einer eignen Datei, obwohl sie nur hinten angehäng ist. |
|
Nach oben |
|
|
ejomi
Anmeldungsdatum: 21.03.2006 Beiträge: 4
|
Verfasst am: 25.03.2006, 15:47 Titel: |
|
|
Michael Frey hat Folgendes geschrieben: | Man könnte die Zweite Datei (also die Textdatei) einfach Huckepack auf die Exe Datei aufsetzen. |
... das klingt gut! Ich versuche mal, mich in die Technik reinzudenken: ich müsste also vorher die kompilierte Größe des Programms kennen, anschließend mit irgendeinem Trick von außen (mittels eines zweiten Hilfsprogramms und BINARY APPEND oder so ähnlich) meine Daten an diese EXE pappen. Dem Programm selbst hatte ich seine eigene, kompilierte Größe als Festwert eingepflanzt, sodaß es jetzt zielsicher per SEEK die betreffenden Daten hinter dem "offiziellen" Programm-Ende aus seiner eigenen EXE-Datei auf der Festplatte einlesen kann - sehe ich das richtig?
Das bedeutet, der ganze Kram wird erst während der Laufzeit des fertigen Programms auseinandergedröselt - während der Entwicklung habe ich zunächst die Daten nicht verfügbar - ich kann also nur "ins Dunkle" programmieren (damit könnte ich aber klarkommen wenn ich z.B.feste, exakt vorausberechenbare Satz- und Feldlängen für die später anzuhängenden Daten verwende) ... oder könnte Dein Vorschlag einfacher realisiert werden?
Was sagt denn eigentlich die Programmausführung, wenn sie das EOF nicht an der erwarteten Stelle findet? Kann man wirklich an EXE-Dateien einfach irgendwelchen Müll anhängen, ohne dass das Programm etwas davon merkt??
Gruß vom - mittlerweile wieder etwas optimistischeren - "ejomi" ! |
|
Nach oben |
|
|
Michael Frey
Anmeldungsdatum: 18.12.2004 Beiträge: 2577 Wohnort: Schweiz
|
Verfasst am: 25.03.2006, 18:43 Titel: |
|
|
Denn "Müll" wie du in so schon nenst, kannst du z.B. bei einem 2000 Byte grössen Programm auch erst ab 3000 Byte anhängen.
Damit bleiben dir 1000 Byte für Künftige Erweiterungen.
Denn Plätz zwischen Programm und Daten füllst du einfach mit Nullen auf.
Zitat: | Kann man wirklich an EXE-Dateien einfach irgendwelchen Müll anhängen, ohne dass das Programm etwas davon merkt?? |
Ich denke ja, aber ich Probiers schnell aus.
(Irgendwo hab ich das gelesen aber noch nie Probiert) |
|
Nach oben |
|
|
anihex
Anmeldungsdatum: 09.03.2006 Beiträge: 51
|
Verfasst am: 27.03.2006, 13:51 Titel: |
|
|
Zitat: | Kann man wirklich an EXE-Dateien einfach irgendwelchen Müll anhängen, ohne dass das Programm etwas davon merkt?? |
Was denkst du, was Viren machen?
Dieselbe Technik verwenden auch Installationsprogramme
[OT]
Und das mit den DLL's:
Ohne DLL's gäbe es weniger Plu-Ins! Du kannst WinAmp z.B. mit Plug-Ins vollstopfen. Ohne DLL's eher schwer...
Ausserdem kann es die Performance eines Programmes erhöhen, wenn nicht das ganze Programm "in einem Rutsch" geladen wird. DLL's können, dank eines Tricks, nachgeladen werden.
Also den Zahn möchte ich dir da doch eher ziehen
Aber solche DLL's werden bei einer Deinstallation mitgelöscht
Zum Bsp. mit dem Auto:
Stell dir vor, du kaufst ein Auto, du bekommst "nur" die Werkzeuge, die du wirklich brauchst. Sie gehören direkt zum Auto zu. Sobald du es verschrotten willst, kommen die Verkäufer des Wagens und nehmen den Wagen UND das Werkzeug wieder mit. Solltest du dann ein zu großes Auto haben, dass dementsprechend viele Werkzeuge braucht. Dann ist das etwas anderes
[/OT] |
|
Nach oben |
|
|
|