Import Problem

Übersicht

BlitzMax, BlitzMax NG

Allgemein

	Vertex Betreff: Import Problem	Di, Apr 19, 2005 19:51 Antworten mit Zitat
So langsam geht es mir echt auf die Eier! Main.bmx Code: [AUSKLAPPEN] [EINKLAPPEN] Import "DreiDe.bmx" Import "Entity.bmx" Import "Camera.bmx" DreiDe.bmx Code: [AUSKLAPPEN] [EINKLAPPEN] Import Pub.Glew Import "Entity.bmx" Import "Camera.bmx" Type TDreiDe Global ScreenWidth : Int Global ScreenHeight : Int Function Graphics3D(Width:Int, Height:Int) TDreiDe.ScreenWidth = Width TDreiDe.ScreenHeight = Height TEntity.Init = 1 TCamera.Init = 1 End Function End Type Entity.bmx Code: [AUSKLAPPEN] [EINKLAPPEN] Type TEntity Global Init : Int Field Name : String End Type Camera.bmx Code: [AUSKLAPPEN] [EINKLAPPEN] Import "DreiDe.bmx" Import "Entity.bmx" Type TCamera Extends TEntity Global Init : Int Field Viewport : Int[4] Method New() Self.Viewport = [0, 0, TDreiDe.ScreenWidth, TDreiDe.ScreenHeight] End Method End Type Ganz dumme Frage: Warum geht das nicht? mfg olli
vertex.dreamfall.at \| GitHub

Vertex

Betreff: Import Problem

Di, Apr 19, 2005 19:51
Antworten mit Zitat

So langsam geht es mir echt auf die Eier!

Main.bmx
Code: [AUSKLAPPEN]

Import "DreiDe.bmx"
Import "Entity.bmx"
Import "Camera.bmx"

DreiDe.bmx
Code: [AUSKLAPPEN]

Import Pub.Glew

Import "Entity.bmx"
Import "Camera.bmx"

Type TDreiDe
Global ScreenWidth : Int
Global ScreenHeight : Int

Function Graphics3D(Width:Int, Height:Int)
   TDreiDe.ScreenWidth = Width
   TDreiDe.ScreenHeight = Height

   TEntity.Init = 1
   TCamera.Init = 1
End Function
End Type

Entity.bmx
Code: [AUSKLAPPEN]

Type TEntity
Global Init : Int

Field Name : String
End Type

Camera.bmx
Code: [AUSKLAPPEN]

Import "DreiDe.bmx"
Import "Entity.bmx"

Type TCamera Extends TEntity
Global Init : Int

Field Viewport : Int[4]

Method New()
Self.Viewport = [0, 0, TDreiDe.ScreenWidth, TDreiDe.ScreenHeight]
End Method
End Type

Ganz dumme Frage: Warum geht das nicht?

mfg olli

vertex.dreamfall.at | GitHub

	Dreamora	Di, Apr 19, 2005 22:20 Antworten mit Zitat
Weil du nicht rekursiv importieren darfst! Das heisst wenn Modul A ein Modul B importiert, darf nicht umgekehrt B A importieren Was die Typedeklarationen betrifft: Eine zentrale File machen, in denen die Grundtypen abstrakt deklariert sind und diese dann einbinden um beim erzeugen die abstrakten Typen durch echte Instanzieren. (also so ähnlich wie in Java) Dann ersparst du dir den import von "DreiDe.bmx" in Camera PS: Du hast in Camera schon ein import "entity.bmx", brauchst es also in DreiDe nimmer, da schon gelinkt. Das wäre dann der nächste Error gewesen, mehrfache Deklaration von TEntity Du kannst die imports als einen nach unten wachsenden Baum (im informatiksinne ) anschauen, in welchem keine 2 Äste gleiche Blätter haben dürfen, noch dürfen sie nach oben gehen (was für eine rekursive verlinkung mit sich selbst von nöten wäre) Wenn dir das keinen Sinn ergibt kann ich dir sonst gerne ein Beispiel schreiben morgen oder so und online stellen
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Di, Apr 19, 2005 22:20
Antworten mit Zitat

Weil du nicht rekursiv importieren darfst!

Das heisst wenn Modul A ein Modul B importiert, darf nicht umgekehrt B A importieren
Was die Typedeklarationen betrifft: Eine zentrale File machen, in denen die Grundtypen abstrakt deklariert sind und diese dann einbinden um beim erzeugen die abstrakten Typen durch echte Instanzieren. (also so ähnlich wie in Java)
Dann ersparst du dir den import von "DreiDe.bmx" in Camera

PS: Du hast in Camera schon ein import "entity.bmx", brauchst es also in DreiDe nimmer, da schon gelinkt. Das wäre dann der nächste Error gewesen, mehrfache Deklaration von TEntity Wink

Du kannst die imports als einen nach unten wachsenden Baum (im informatiksinne ) anschauen, in welchem keine 2 Äste gleiche Blätter haben dürfen, noch dürfen sie nach oben gehen (was für eine rekursive verlinkung mit sich selbst von nöten wäre)

Wenn dir das keinen Sinn ergibt kann ich dir sonst gerne ein Beispiel schreiben morgen oder so und online stellen Smile

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

	Vertex	Di, Apr 19, 2005 22:32 Antworten mit Zitat
Das darf jedoch nicht sein, das man eben nicht mehrfach Importieren darf. Wie schon im Chat gesagt, muss das wie in C++ geregelt sein. Kann nicht sein, das ich extra abstrakte Klassen für so ein Kindergartenscheiß anlegen muss, nur weil BMax einfach zu blöd dazu ist, soetwas zu supporten. Anscheinend muss ich doch mal wieder den Griff ins Klo machen, und Includes verwenden. So lange Entwicklungszeit und nichtmal soetwas essentielles wie das eingearbeitet. Purer Masochismus! mfg olli Edit: Um das noch klar zu stellen: Wenn ich eine Main.bmx anlege, wo alle Imports die ich benötige aufliste, klappt das ebenfalls nicht. Insofern ist es ein kompletter Wiederspruch zur Import-Logik. Mark will anscheinend, das man alles nur in eine Datei schreibt, und man dann damit Glückich sein soll.
vertex.dreamfall.at \| GitHub

Vertex

Di, Apr 19, 2005 22:32
Antworten mit Zitat

Das darf jedoch nicht sein, das man eben nicht mehrfach Importieren darf. Wie schon im Chat gesagt, muss das wie in C++ geregelt sein.

Kann nicht sein, das ich extra abstrakte Klassen für so ein Kindergartenscheiß anlegen muss, nur weil BMax einfach zu blöd dazu ist, soetwas zu supporten. Anscheinend muss ich doch mal wieder den Griff ins Klo machen, und Includes verwenden. So lange Entwicklungszeit und nichtmal soetwas essentielles wie das eingearbeitet. Purer Masochismus!

mfg olli

Edit: Um das noch klar zu stellen: Wenn ich eine Main.bmx anlege, wo alle Imports die ich benötige aufliste, klappt das ebenfalls nicht. Insofern ist es ein kompletter Wiederspruch zur Import-Logik. Mark will anscheinend, das man alles nur in eine Datei schreibt, und man dann damit Glückich sein soll.

vertex.dreamfall.at | GitHub

	regaa	Di, Apr 19, 2005 22:42 Antworten mit Zitat
Tatsache O_O. Tjo, dann mach es eben mit Includes .
UltraMixer Professional 3 - Download QB,HTML,CSS,JS,PHP,SQL,>>B2D,B3D,BP,BlitzMax,C,C++,Java,C#,VB6 , C#, VB.Net

regaa

Di, Apr 19, 2005 22:42
Antworten mit Zitat

Tatsache O_O. Tjo, dann mach es eben mit Includes . Laughing

UltraMixer Professional 3 - Download
QB,HTML,CSS,JS,PHP,SQL,>>B2D,B3D,BP,BlitzMax,C,C++,Java,C#,VB6 , C#, VB.Net

	Vertex	Di, Apr 19, 2005 22:57 Antworten mit Zitat
Includes -> lahm, da bei jedem neu kompilieren, alles neu kompiliert wird. Ich habe es jetzt einfach so gemacht, das ich extra eine HardwareInfo.bmx aneglegt habe, die ich dann so oft Importieren kann, wie ich will. Naja, wie es aussieht, ist BMax noch nicht so das Wahre mfg olli
vertex.dreamfall.at \| GitHub

Vertex

Di, Apr 19, 2005 22:57
Antworten mit Zitat

Includes -> lahm, da bei jedem neu kompilieren, alles neu kompiliert wird. Ich habe es jetzt einfach so gemacht, das ich extra eine HardwareInfo.bmx aneglegt habe, die ich dann so oft Importieren kann, wie ich will.

Naja, wie es aussieht, ist BMax noch nicht so das Wahre Sad

mfg olli

vertex.dreamfall.at | GitHub

	Dreamora	Mi, Apr 20, 2005 1:03 Antworten mit Zitat
Naja, würde man die Codestrukturierung vorher auf modulares OO Design stellen, würden solche Probleme garnicht erst entstehen. Hat wenig Zweck wenn man OO Vorteile nutzen will und mit prozeduralem Design auffährt, das muss fast zwangsweise zu Problemen führen. Aber das kann immer Mal passieren, vor allem wenn man beginnt zu programmieren und alles dann zu gut und schnell entsteht, so das man garnet dazu motiviert ist, die Struktur zu designen bevor man mit programmieren beginnt. Und wie C++ muss das definitiv net geregelt sein. 20 Jahre alten und schon lange veralteten Programmiergrundsätzen nachzueifern wäre vollkommen hirnverbrannt. Deswegen finde ich es garnicht schlecht, dass einige der Verhaltensmuster von Java her kommen. Mag sein, dass einige davon ein wenig mühsam sind, aber sie sind C++ Verhaltensmuster meist vorzuziehen. Im Falle von DreiDe ist es auch so, dass du nicht alles als Abstract definieren musst (wobei das ja eh nur aus einem copy - past - code löschen besteht) Du musst nur den "Linking Tree" / Abhängigkeitsbaum richtig aufbauen (mittels zeichnen eines Diagramms, was eigentlich vor dem programmieren schon geschehen hätte sollen, wir sind ja hier keine C++ Hacker), dadurch Fallen viele Probleme meist ziemlich schnell weg (und man sieht auch Designschwächen oder Orte wo es bei einer Erweiterung zu Problemen kommen könnte) 3 Schritte um ein bestehendes System "aufzuräumen": Voraussetzung: jede Klasse ist in ihrer eigenen BMX File 1. Schauen, welche Klassen wie grundlegend sind. Jene, die das Fundament darstellen wie TEntity, von welchen alle anderen dann abgeleitet werden oder abhängen, stehen zu oberst im Tree und importieren nichts! 2. Danach schaut man erst einmal auf die abgeleiteten klassen. Diese definieren danach was was in welcher Reihenfolge importieren muss. Da BM keinen Multi Inherit erlaubt, kann es dabei auch zu keinen Importproblemen kommen, da man immer nur von einer Klasse ableitet. 3. Dann kommen jene, die am häufigsten zu Problemen führen: Die Klassen, die als Eigenschaften Referenzen auf andere Klassen haben. Im besten Falle kann man hier einfach die entsprechenden Klassen importieren. Im weniger optimalen Fall muss die Klasse im Tree vor die Klasse die es versucht als Eigenschaft zu verwenden. In diesem und eigentlich nur in diesem Fall muss man eine abstrakte Deklaration einer Elternklasse dieser Klassen erzeugen um Referenzen auf jene zu erzeugen, welche zur Laufzeit mit Referenzen auf die tatsächliche Klasse gefüttert werden. Dies erzwingt dann leider bei der Nutzung dieser Felder in anderen Klassen mitunter auch IF Type () checks. Spezialfall: Es gibt Klassen, die nur für genau 1 andere Klasse von Bedeutung sind. In diesem Fall ist es am ratsamsten, diese Klassen dann zusammen mit ihren Nutzern in einer bmx unterzubringen. Übrigens: Ich kenne das Problem von Import nur zur genüge. Hatte mein Spiel erst auch falsch zusammengeschustert und musste es dann nochmal auseinander nehmen. Aber das Resultat davon ist jetzt beträchtlich einfacher zu handhabender Code und kaum Probleme, wenn ich ihn um Features erweitere in Form von neuen abgeleiteten Klassen. Was in so einem Fall natürlich praktisch wäre, wäre ein Programm, dass die Klassenhierarchie visualisiert (BON Diagram), bzw wo man direkt die Klassenhierarchie darin visuel erstellen kann und sich daraus danach den Code generieren lassen kann. Im optimalsten Falle gleich mit den entsprechenden Funktionen und Methoden die die Klassen haben sollen und weiteren Dingen, die wichtig sind. Das ist allerdings auch mein zukünftiges Projekt, da ich es bei der Arbeit mit Eiffel zu schätzen gelernt habe, dadurch Probleme viel früher schon visuel erkennen zu können. Das einzige was mir dafür erst fehlt ist ein GUI Modul, weswegen ich derzeit mit Hilfe von BM etwas einfaches in der Art erstelle (geht für grundlegende Dinge relativ schnell dank Funktionsreferenzen und OO), damit ich mit Prototypen beginnen kann. Denn eine derartige Oberfläche braucht relativ viel testen, damit sie wirklich intuitiv funktioniert. Sobald (sollte ich denn) irgendetwas vorzuzeigen habe, wirds irgendwo hier im Board zu finden sein und wenn BM raus ist, natürlich auch zu testen.
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Mi, Apr 20, 2005 1:03
Antworten mit Zitat

Naja, würde man die Codestrukturierung vorher auf modulares OO Design stellen, würden solche Probleme garnicht erst entstehen.
Hat wenig Zweck wenn man OO Vorteile nutzen will und mit prozeduralem Design auffährt, das muss fast zwangsweise zu Problemen führen.
Aber das kann immer Mal passieren, vor allem wenn man beginnt zu programmieren und alles dann zu gut und schnell entsteht, so das man garnet dazu motiviert ist, die Struktur zu designen bevor man mit programmieren beginnt.

Und wie C++ muss das definitiv net geregelt sein. 20 Jahre alten und schon lange veralteten Programmiergrundsätzen nachzueifern wäre vollkommen hirnverbrannt.
Deswegen finde ich es garnicht schlecht, dass einige der Verhaltensmuster von Java her kommen. Mag sein, dass einige davon ein wenig mühsam sind, aber sie sind C++ Verhaltensmuster meist vorzuziehen.

Im Falle von DreiDe ist es auch so, dass du nicht alles als Abstract definieren musst (wobei das ja eh nur aus einem copy - past - code löschen besteht)

Du musst nur den "Linking Tree" / Abhängigkeitsbaum richtig aufbauen (mittels zeichnen eines Diagramms, was eigentlich vor dem programmieren schon geschehen hätte sollen, wir sind ja hier keine C++ Hacker), dadurch Fallen viele Probleme meist ziemlich schnell weg (und man sieht auch Designschwächen oder Orte wo es bei einer Erweiterung zu Problemen kommen könnte)

3 Schritte um ein bestehendes System "aufzuräumen":
Voraussetzung: jede Klasse ist in ihrer eigenen BMX File

1. Schauen, welche Klassen wie grundlegend sind. Jene, die das Fundament darstellen wie TEntity, von welchen alle anderen dann abgeleitet werden oder abhängen, stehen zu oberst im Tree und importieren nichts!

2. Danach schaut man erst einmal auf die abgeleiteten klassen. Diese definieren danach was was in welcher Reihenfolge importieren muss.
Da BM keinen Multi Inherit erlaubt, kann es dabei auch zu keinen Importproblemen kommen, da man immer nur von einer Klasse ableitet.

3. Dann kommen jene, die am häufigsten zu Problemen führen:
Die Klassen, die als Eigenschaften Referenzen auf andere Klassen haben.
Im besten Falle kann man hier einfach die entsprechenden Klassen importieren.
Im weniger optimalen Fall muss die Klasse im Tree vor die Klasse die es versucht als Eigenschaft zu verwenden.
In diesem und eigentlich nur in diesem Fall muss man eine abstrakte Deklaration einer Elternklasse dieser Klassen erzeugen um Referenzen auf jene zu erzeugen, welche zur Laufzeit mit Referenzen auf die tatsächliche Klasse gefüttert werden.
Dies erzwingt dann leider bei der Nutzung dieser Felder in anderen Klassen mitunter auch IF Type () checks.

Spezialfall: Es gibt Klassen, die nur für genau 1 andere Klasse von Bedeutung sind. In diesem Fall ist es am ratsamsten, diese Klassen dann zusammen mit ihren Nutzern in einer bmx unterzubringen.

Übrigens: Ich kenne das Problem von Import nur zur genüge. Hatte mein Spiel erst auch falsch zusammengeschustert und musste es dann nochmal auseinander nehmen. Aber das Resultat davon ist jetzt beträchtlich einfacher zu handhabender Code und kaum Probleme, wenn ich ihn um Features erweitere in Form von neuen abgeleiteten Klassen.

Was in so einem Fall natürlich praktisch wäre, wäre ein Programm, dass die Klassenhierarchie visualisiert (BON Diagram), bzw wo man direkt die Klassenhierarchie darin visuel erstellen kann und sich daraus danach den Code generieren lassen kann. Im optimalsten Falle gleich mit den entsprechenden Funktionen und Methoden die die Klassen haben sollen und weiteren Dingen, die wichtig sind.
Das ist allerdings auch mein zukünftiges Projekt, da ich es bei der Arbeit mit Eiffel zu schätzen gelernt habe, dadurch Probleme viel früher schon visuel erkennen zu können.
Das einzige was mir dafür erst fehlt ist ein GUI Modul, weswegen ich derzeit mit Hilfe von BM etwas einfaches in der Art erstelle (geht für grundlegende Dinge relativ schnell dank Funktionsreferenzen und OO), damit ich mit Prototypen beginnen kann. Denn eine derartige Oberfläche braucht relativ viel testen, damit sie wirklich intuitiv funktioniert.

Sobald (sollte ich denn) irgendetwas vorzuzeigen habe, wirds irgendwo hier im Board zu finden sein und wenn BM raus ist, natürlich auch zu testen.

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

	Nemesis	Mi, Apr 20, 2005 15:15 Antworten mit Zitat
Muss Dreamora im großen und ganzen recht geben. Mal abgesehen davon das das in C++ auch noch so geht, du machst es da ja auch mit den abstracten grundtypen in form eines header files. das ist auch nix anderes.

Nemesis

Mi, Apr 20, 2005 15:15
Antworten mit Zitat

Muss Dreamora im großen und ganzen recht geben.

Mal abgesehen davon das das in C++ auch noch so geht, du machst es da ja auch mit den abstracten grundtypen in form eines header files. das ist auch nix anderes.

	Dreamora	Do, Apr 21, 2005 20:30 Antworten mit Zitat
Ich hätte übrigens noch einen Vorschlag, auf dessen Idee ich vorher nicht wirklich gekommen bin: Ich weiss nicht ob du je mit Sprachen in Kontakt gekommen bist, die Cluster benutzen (Cluster ist eigentlich ein Ordner in welchem Sources sind. Dieser Cluster wird dann danach zu 1 File compiliert). Aber in BM könntest du deinen Source zb so strukturieren, dass du es in Cluster zusammenfasst und dann je Cluster eine 1 bmx machen, die alle anderen Sources aus dem Cluster included. Danach dann einfach diese einzige Datei importen ausserhalb des Clusters Dann wird der Cluster jeweils nur neu compiliert, wenn du eine Datei aus dem Cluster änderst. Damit sollte es möglich sein, gleich alle hier bemängelten Fliegen runterzuschlagen
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Do, Apr 21, 2005 20:30
Antworten mit Zitat

Ich hätte übrigens noch einen Vorschlag, auf dessen Idee ich vorher nicht wirklich gekommen bin:

Ich weiss nicht ob du je mit Sprachen in Kontakt gekommen bist, die Cluster benutzen (Cluster ist eigentlich ein Ordner in welchem Sources sind. Dieser Cluster wird dann danach zu 1 File compiliert).

Aber in BM könntest du deinen Source zb so strukturieren, dass du es in Cluster zusammenfasst und dann je Cluster eine 1 bmx machen, die alle anderen Sources aus dem Cluster included. Danach dann einfach diese einzige Datei importen ausserhalb des Clusters Smile

Dann wird der Cluster jeweils nur neu compiliert, wenn du eine Datei aus dem Cluster änderst.
Damit sollte es möglich sein, gleich alle hier bemängelten Fliegen runterzuschlagen Wink

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

	ThorbenSchröder Ehemaliger Admin	Do, Jun 02, 2005 18:15 Antworten mit Zitat
Hm, ich bin zu doof dafür. Wie genau würde ich so etwas machen: 1. Datei: Hauptprogramm 2. Datei: Managed alle Unterdateien 3. Datei: Konstanten wie Beispielsweise die Bildschirmbreite 4. Datei: Ein Tileset-Type 5. Datei: Ein Type eines Layers, dass ein Array vom Tileset-Typ haben soll mit Imports bekomm ich es einfach nicht gebacken, denke ich nicht objekt-orientiert? Thorben

ThorbenSchröder

Ehemaliger Admin

Do, Jun 02, 2005 18:15
Antworten mit Zitat

Hm, ich bin zu doof dafür.
Wie genau würde ich so etwas machen:

1. Datei: Hauptprogramm
2. Datei: Managed alle Unterdateien
3. Datei: Konstanten wie Beispielsweise die Bildschirmbreite
4. Datei: Ein Tileset-Type
5. Datei: Ein Type eines Layers, dass ein Array vom Tileset-Typ haben soll

mit Imports bekomm ich es einfach nicht gebacken, denke ich nicht objekt-orientiert?

Thorben

	Dreamora	Do, Jun 02, 2005 19:27 Antworten mit Zitat
Was muss schreibzugriff auf was haben? Von dem was da so steht würde ich folgendes nehmen: a << b= a importiert b 1 << 2 2 << 3 2 << 5 << 4 In BM kann man nicht ganz OO mässig denken, zumindest nicht so wie es bei alten OO Sprachen möglich war. Wenn es irgendwo "zyklische Referenzen" gibt, dann muss man aus diesen Dateien dann jeweils einen Cluster machen (also eine Hauptdatei dafür, welche die zyklisch verbundenen bmx included) und diesen dann importen. Dadurch wird der Cluster dann nur neu compiled, wenn sich eine unterdatei ändert (mit quick build), womit man vorteile aus der import und der include welt hat. Zumindest solange die Clustergrösse sich in Grenzen hält.
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Do, Jun 02, 2005 19:27
Antworten mit Zitat

Was muss schreibzugriff auf was haben?

Von dem was da so steht würde ich folgendes nehmen:

a << b= a importiert b

1 << 2
2 << 3
2 << 5 << 4

In BM kann man nicht ganz OO mässig denken, zumindest nicht so wie es bei alten OO Sprachen möglich war.
Wenn es irgendwo "zyklische Referenzen" gibt, dann muss man aus diesen Dateien dann jeweils einen Cluster machen (also eine Hauptdatei dafür, welche die zyklisch verbundenen bmx included) und diesen dann importen.

Dadurch wird der Cluster dann nur neu compiled, wenn sich eine unterdatei ändert (mit quick build), womit man vorteile aus der import und der include welt hat. Zumindest solange die Clustergrösse sich in Grenzen hält.

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

	walski Ehemaliger Admin	Fr, Jun 03, 2005 8:41 Antworten mit Zitat
Ok, ich erweiter das ganze nochmal: 1. Datei: Hauptprogramm 2. Datei: Managed alle Unterdateien 3. Datei: Konstanten wie Beispielsweise die Bildschirmbreite 4. Datei: Ein Tileset-Type 5. Datei: Ein Type eines Layers, dass ein Array vom Tileset-Typ haben soll 6. Datei: Ein anderer Type, der auch ein Field vom Tileset-Typ haben soll So, jetzt entspricht das Beispiel meinem Problem Und nu? Thorben
buh!

walski

Ehemaliger Admin

Fr, Jun 03, 2005 8:41
Antworten mit Zitat

Ok, ich erweiter das ganze nochmal:

1. Datei: Hauptprogramm
2. Datei: Managed alle Unterdateien
3. Datei: Konstanten wie Beispielsweise die Bildschirmbreite
4. Datei: Ein Tileset-Type
5. Datei: Ein Type eines Layers, dass ein Array vom Tileset-Typ haben soll
6. Datei: Ein anderer Type, der auch ein Field vom Tileset-Typ haben soll

So, jetzt entspricht das Beispiel meinem Problem Smile

Und nu?

Thorben

buh!

	Jolinah	Fr, Jun 03, 2005 11:59 Antworten mit Zitat
1: Import 2 2: Import 3 Import 5 Import 6 5: Import 4 6: Import 4 So müsste es gehen.

Jolinah

Fr, Jun 03, 2005 11:59
Antworten mit Zitat

1:
Import 2

2:
Import 3
Import 5
Import 6

5:
Import 4

6:
Import 4

So müsste es gehen.

	Dreamora	Fr, Jun 03, 2005 12:28 Antworten mit Zitat
Und sollten 5 und 6 auch noch irgend etwas von einander brauchen, so würde ich aus 4,5,6 einen Cluster bilden, also: 7: Include 4,5,6 (nicht import) und dann 2 import 7
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Fr, Jun 03, 2005 12:28
Antworten mit Zitat

Und sollten 5 und 6 auch noch irgend etwas von einander brauchen, so würde ich aus 4,5,6 einen Cluster bilden, also:

7: Include 4,5,6 (nicht import)

und dann 2 import 7

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

	walski Ehemaliger Admin	Fr, Jun 03, 2005 13:35 Antworten mit Zitat
AHHHH! Ok, ich dachte sowas: Zitat: 5: Import 4 6: Import 4 würde nicht funktionieren... Danke! Thorben
buh!

walski

Ehemaliger Admin

Fr, Jun 03, 2005 13:35
Antworten mit Zitat

AHHHH! Ok, ich dachte sowas:

Zitat:

5:
Import 4

6:
Import 4

würde nicht funktionieren...

Danke!

Thorben

buh!

	Jolinah	Fr, Jun 03, 2005 18:04 Antworten mit Zitat
Bei Import schon, nur bei Include nicht weil da ja der Code zusammengefügt wird.

Jolinah

Fr, Jun 03, 2005 18:04
Antworten mit Zitat

Bei Import schon, nur bei Include nicht weil da ja der Code zusammengefügt wird.

	Dreamora	Fr, Jun 03, 2005 20:11 Antworten mit Zitat
Walski: Es gibt einen Fall wo das nicht erlaubt ist wegen mehrfach import und zwar im Falle 3 import 4,5 4 import 5 da dann 3 explizit etwas versucht zu importieren, was eine andere File bereits enthält.
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Fr, Jun 03, 2005 20:11
Antworten mit Zitat

Walski: Es gibt einen Fall wo das nicht erlaubt ist wegen mehrfach import und zwar im Falle

3 import 4,5
4 import 5

da dann 3 explizit etwas versucht zu importieren, was eine andere File bereits enthält.

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

	Serge	Di, Jun 07, 2005 14:46 Antworten mit Zitat
Dreamora hat Folgendes geschrieben: Und sollten 5 und 6 auch noch irgend etwas von einander brauchen, so würde ich aus 4,5,6 einen Cluster bilden, also: 7: Include 4,5,6 (nicht import) und dann 2 import 7 Wenn ich mir nicht irre klappt so ein Cluster in BM nicht, zumindest hat bei mir, wenn aus 5 irgendwas was von 6 gebraucht hat, BM einen Fehler ausgegeben, außer man importete es dirrect in 5.
http://www.dark-matter-soft.de

Serge

Di, Jun 07, 2005 14:46
Antworten mit Zitat

Dreamora hat Folgendes geschrieben:

Und sollten 5 und 6 auch noch irgend etwas von einander brauchen, so würde ich aus 4,5,6 einen Cluster bilden, also:

7: Include 4,5,6 (nicht import)

und dann 2 import 7

Wenn ich mir nicht irre klappt so ein Cluster in BM nicht, zumindest hat bei mir, wenn aus 5 irgendwas was von 6 gebraucht hat, BM einen Fehler ausgegeben, außer man importete es dirrect in 5.

http://www.dark-matter-soft.de

	Dreamora	Di, Jun 07, 2005 15:03 Antworten mit Zitat
Cluster benutzen include nicht import. Dann enden 4,5,6 danach in 1 einzelnen Datei und Object File, die importiert wird. Das dient genau dazu, dem zyklischen Import zu entgehen der sonst in einem solchen Fall entstehen würde.
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Di, Jun 07, 2005 15:03
Antworten mit Zitat

Cluster benutzen include nicht import.

Dann enden 4,5,6 danach in 1 einzelnen Datei und Object File, die importiert wird.
Das dient genau dazu, dem zyklischen Import zu entgehen der sonst in einem solchen Fall entstehen würde.

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Übersicht

BlitzMax, BlitzMax NG

Allgemein

Nach Oben

BlitzBasic Portal

Import Problem

Betreff: Import Problem