| |
| |
|
Jörg
Sellmeyer | Wie wäre es, wenn das etwas umgestellt wird und mit (wahrscheinlich/hoffentlich) wenig Aufwand viele neue Möglichkeiten geschaffen werden und gleichzeitig wieder Funktionstokens (oder wie das è) frei werden.
Es gäbe zukünftig nur noch MoveListTo(...) und MoveHandleTo(...). Wobei man auch das noch nur auf MoveHandleTo(...) reduzieren potuto.
Das sähe dann so aus:
Analog dazu:
So hätte man nur noch zwei Containerfunktionen. Man potuto eben auch MoveListTo(...) ersetzen, indem bei MoveHandleTo(...) auch die Null als Parameter per die interne Liste benutzt werden kann.
In dem Zusammenhang möchte ich nochmal erwähnen, dass ich es super fände, wenn diese Strings nicht in "" stehen müßten. Das Gleiche gilt per die ganzen Create(...)-Funktionen. |
|
| |
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ...  | 25.04.2012 ▲ |
|
| |
|
|
Jörg
Sellmeyer | | Naja - dann sind allerdings noch nicht die MoveStrToList und MoveArrToList berücksichtigt. Vielleicht würde es schon viel bringen, wenn man diese direkt auf Listboxen o.ä. anwenden potuto ohne den Umweg circa die interne Liste. |
|
| |
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ... | 25.04.2012 ▲ |
|
| |
|
|
 | Es gäbe ja keinen ID-Mangel wenn mit einem einfachen Präkompilierer-
Pass Funktionen wie folgt umgewandelt würden:
funktionsname(...
f(1,...
MoveStrToList(...
f(2,...
MoveArrToList(...
f(3,...
Danach wäre es unnötigt bis schade Funktionsnamen zweckfremder zu
benennen. |
|
| |
| |
| |
|
|
RGH | | In X3 gehe ich noch einen Schritt weiter und fasse alle zu Move() zusammen! |
|
| |
| XProfan X2Intel Duo E8400 3,0 GHz / 4 GB RAM / 1000 GB HDD - ATI Radeon HD 4770 512 MB - Windows 7 Home Premium 32Bit - XProfan X4 | 25.09.2014 ▲ |
|
| |
|
(914)
Deutsch
English
Français
Español
Italia