blob: 2c7736ac898cd8bf4842db535ab34b031bd04af8 [file] [log] [blame]
Zesstra953f9972017-02-18 15:37:36 +01001
2CustomizeObject()
3*****************
4
5
6FUNKTION
7========
8
9 string CustomizeObject();
10
11
12DEFINIERT IN
13============
14
15 /std/virtual/v_compiler.c
16
17
18ARGUMENTE
19=========
20
21 keine
22
23
24RUeCKGABEWERT
25=============
26
27 Den Objektnamen, den das zuletzt erzeugte Objekt (welches gerade die
28 Funktion aufruft) spaeter vom Driver bekommen wird.
29
30
31BESCHREIBUNG
32============
33
34 Diese Funktion ist aus dem Grunde da, da zum Zeitpunkt des Clonens des
35 VC-Objektes (P_STD_OBJECT) dieses Objekt ja noch nicht weiss Wer
36 oder Was es spaeter mal sein wird.
37 Deshalb kann dieses VC-Objekt im create() (und nur da!) die Funktion
38 CustomizeObject() in dem virtual_compiler aufrufen, welches das Objekt
39 geclont hat und bekommt von diesem den Objektnamen zureck, welches es
40 spaeter mal bekommen wird.
41 Da das VC-Objekt vom VC geclont wurde, ist previous_object() im create()
42 des VC-Objektes der VC, in dem man CustomizeObject() ruft.
43
44
45BEMERKUNGEN
46===========
47
48 Das CustomizeObject() im Standard-VC gibt nur den zukuenftigen Objektnamen
49 zurueck und macht sonst nix.
50
51
52BEISPIELE
53=========
54
55 create() eines VC-Objektes:
56
57
58
59 protected void create() {
60 ...
61
62
63
64 // wer bin ich denn eigentlich?
65 string myname = previous_object()->CustomizeObject();
66 switch(myname) {
67 // Kram konfigurier, ja nach myname...
68 }
69
70
71
72 ...
73 }
74
75
76SIEHE AUCH
77==========
78
79 virtual_compiler
80 CustomizeObject(), Validate(), NoParaObjects(),
81 P_COMPILER_PATH, P_PARA
82 /std/virtual/v_compiler.c
83
8421.10.2007, Zesstra