| MG Mud User | 88f1247 | 2016-06-24 23:31:02 +0200 | [diff] [blame^] | 1 | CustomizeObject() |
| 2 | |
| 3 | FUNKTION: |
| 4 | string CustomizeObject(); |
| 5 | |
| 6 | DEFINIERT IN: |
| 7 | /std/virtual/v_compiler.c |
| 8 | |
| 9 | ARGUMENTE: |
| 10 | keine |
| 11 | |
| 12 | RUeCKGABEWERT: |
| 13 | Den Objektnamen, den das zuletzt erzeugte Objekt (welches gerade die |
| 14 | Funktion aufruft) spaeter vom Driver bekommen wird. |
| 15 | |
| 16 | BESCHREIBUNG: |
| 17 | Diese Funktion ist aus dem Grunde da, da zum Zeitpunkt des Clonens des |
| 18 | VC-Objektes (P_STD_OBJECT) dieses Objekt ja noch nicht weiss Wer |
| 19 | oder Was es spaeter mal sein wird. |
| 20 | Deshalb kann dieses VC-Objekt im create() (und nur da!) die Funktion |
| 21 | CustomizeObject() in dem virtual_compiler aufrufen, welches das Objekt |
| 22 | geclont hat und bekommt von diesem den Objektnamen zureck, welches es |
| 23 | spaeter mal bekommen wird. |
| 24 | Da das VC-Objekt vom VC geclont wurde, ist previous_object() im create() |
| 25 | des VC-Objektes der VC, in dem man CustomizeObject() ruft. |
| 26 | |
| 27 | BEMERKUNGEN: |
| 28 | Das CustomizeObject() im Standard-VC gibt nur den zukuenftigen Objektnamen |
| 29 | zurueck und macht sonst nix. |
| 30 | |
| 31 | BEISPIELE: |
| 32 | create() eines VC-Objektes: |
| 33 | |
| 34 | protected void create() { |
| 35 | ... |
| 36 | |
| 37 | // wer bin ich denn eigentlich? |
| 38 | string myname = previous_object()->CustomizeObject(); |
| 39 | switch(myname) { |
| 40 | // Kram konfigurier, ja nach myname... |
| 41 | } |
| 42 | |
| 43 | ... |
| 44 | } |
| 45 | |
| 46 | SIEHE AUCH: |
| 47 | virtual_compiler |
| 48 | CustomizeObject(), Validate(), NoParaObjects(), |
| 49 | P_COMPILER_PATH, P_PARA |
| 50 | /std/virtual/v_compiler.c |
| 51 | ---------------------------------------------------------------------------- |
| 52 | 21.10.2007, Zesstra |