PureBasic 4.40 final released

[Kiffi]

Wieso verdaddle ich Speicher?
Das ist mir nicht ganz klar.

ich meinte eigentlich Dein Beispiel oben (mit Multiplikator 100) und nicht Dein optimiertes Beispiel (mit Multiplikator 3).

Code: Alles auswählen

NewList spieler()
AddElement(spieler())
AddElement(spieler())
AddElement(spieler())
AddElement(spieler())
AddElement(spieler())
ForEach spieler()
  pos=ListIndex(spieler())+1
  Debug pos*100+a
Next

da reservierst Du in Hunderterschritten Gadgetspeicher.

Ich mache sowas immer mit #PB_ANY.

Und bei Deinem Buttongadget-Beispiel hast Du Dir wohlweislich den einzigen
Teil rausgepickt, der sich mit einer Schleife abfrühstücken lässt, Du Schlingel.

Ich schubse lieber ein paar Gadgets mit der Maus auf nem Fenster herum.
Da sehe ich sofort, wie das Ergebnis aussehen wird. Ist Gewohnheitssache
und hat sich beispielsweise bei Projekten, die ich mit VB.Net erstelle,
bestens bewährt.

Aber ansonsten will ich Dir ja gerne zustimmen. Wenn es um Listen-Darstellung
von Gadgets geht, rennst Du bei mir offene Türen ein.

Grüße ... Kiffi

[ts-soft]

Für Dialoge nimmt man nen Designer, für flexible Fenster macht man es sich selbst
Kiffies Beispiel zeigt ja einen Dialog, den kann man am besten mit einem Designer machen.

Wenn man dafür so eine lahme Umwicklungsumgebung wie Visuell Studio aufrufen muß, dann
vergeht mir die Lust bevor man angefangen hat

[Macros]

Wird der wirklich reserviert, nur weil 100 dazwischen sind?
#PB_ANY gibt doch auch gleich astronomische Werte zurück.
Das kann ich bei meinen Schleifen allerdings auch nicht ändern, ich organisiere meinen Code nach Nummern.
Je nach Projekt z.B. Spieler 1 Gadgets 100-199,
oder Panel 1 im Fenster kriegt die Reichweite.
(Das bedeutet natürlich auch, das noch etwa 50 Gadgets innerhalb des Bereichs belegt werden)

Schleifen würde ich im obrigen Falle übrigens überall wo rot markiert benutzen:


Es blieben also 5+3(*2)+1(*4)+1(*4)+1(*12)+1(*8)+1(*5)=13 Gadgets für mich zum Beschreiben ^^

[ts-soft]

> Wird der wirklich reserviert, nur weil 100 dazwischen sind?
Ja, es wird Speicher von der größe der Gadget-Structure * 100 reserviert (siehe SDK für mehr Info's).

> #PB_ANY gibt doch auch gleich astronomische Werte zurück
Das sind pointer zu der Structure, hierbei wird kein unnötiger Speicher reserviert.

Gruß
Thomas

[freak]

Ein VD in Zusammenhang mit einem schicken Eventhandling (a la EasyVENT)
wäre schon der Kracher. Leider ist zumindest der feature request
nach einem alternativen nativen Eventhandling von Fred abgebügelt worden.

http://www.purebasic.fr/english/viewtop ... =3&t=39805

Interessante Interpretation von

There is nothing confusing in the current event handler, it's even more logical than callback based one.

Dein Wunsch ist durchaus Teil unseres längerfristigen Plans für PB, aber weil das doch eine größere Aktion wäre und unsere Zeit für PB momentan etwas limitiert ist machen wir da noch keine konkreten Versprechungen.

[Kurzer]

Apropos langfrstiger Plan: Was ich mir in PB für die Zukunft wünsche ist eine optische Rückmeldung im Bereich Prozeduren innerhalb der Werkzeugtafel die einem anzeigt in welcher Prozedur man sich gerade befindet.

Ich weiß, daß das mal mit einem "Man sollte schon wissen, wo man sich in seinem Code befindet" kommentiert wurde. Das ist ja auch richtig, aber mich nervt es genau genommen nur in einer Situation: Wenn ich den Code nach etwas durchsuche und dann mit F3 quer durch die Datei weitersuche. In manchen includes habe ich 30 oder mehr Prozeduren drin und wenn die Suche dann irgendwo den gesuchten Ausdruck findet, dann weiß ich nicht mehr unbeding in welcher Prozedur das ist.

Zumindest nicht, wenn man den Prozedurkopf nicht sehen kann, weil er nach oben rausgescrollt ist oder man auf dem netbook eh nicht so sehr viele Zeilen sehen kann.



Ich weiß nicht, ob das komplizierter umzusetzen ist als das neue Projektmanagement, aber so eine Markierung der aktuellen Prozedur in der Werkzeugtafel, das wäre schon cool.

[Kiffi]

Interessante Interpretation von

There is nothing confusing in the current event handler, it's even more logical than callback based one.

Mit meinem Schulenglisch würde ich das wie folgt übersetzen:

"An dem derzeitigen Eventhandler ist nichts verwirrendes. Er ist sogar logischer als ein callback-basierter."

und das würde ich halt so interpretieren, dass das bestehende Eventhandling
(so, wie es ist) voll ausreicht und kein Bedarf für ein alternatives Eventhandling besteht.

Sollte ich das fehlinterpretiert haben, so nehme ich natürlich meine
'abgebügelt'-Aussage gerne zurück.

Dein Wunsch ist durchaus Teil unseres längerfristigen Plans für PB, aber weil das doch eine größere Aktion wäre und unsere Zeit für PB momentan etwas limitiert ist machen wir da noch keine konkreten Versprechungen.

na, das ist doch mal was, worauf man sich freuen kann!

Danke für den kleinen Blick hinter die Kulissen & Grüße ... Kiffi