| |
| |
|
| - Page 1 - |
|
Jörg
Sellmeyer | Die Ausgaben mit print GetText$ erfolgen hintereinander, statt untereinander:
KompilierenMarkierenSeparieren
Proc GetStatusText
parameters hndl&,part&
Declare buf#,text$
Dim buf#,512
sendmessage(hndl&,1026,part&,buf#)
text$ = string$(buf#,0)
Dispose buf#
return text$
endproc
cls
Declare s#
Dim s#,12
Long s#,0 = 50, 280, -1
var st& = Create("StatusWindow",%Hwnd,"",3,s#)
dispose s#
settext st&,0,"Feld 1"
settext st&,1,"Feld 2"
settext st&,2,"Feld 3"
print gettext$(st&,0) + ""
print gettext$(st&,1)
print gettext$(st&,2)
print
print "Nun mit Sendmessage"
print GetStatusText(st&,0)
print GetStatusText(st&,1)
print GetStatusText(st&,2)
waitinput
|
|
| |
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ...  | 04.11.2011 ▲ |
|
| |
|
|
| |
| |
| - Page 1 - |
|
Jörg
Sellmeyer | | Ich glaube, es hängt damit zusammen, daß eine Funktion den Abschluß des Print-Befehls bildet. |
|
| |
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ... | 04.11.2011 ▲ |
|
| |
|
|
 | Naja,
AddString(... ist auch eine Funktion und dabei bricht Print richtig um.
Da wird Roland wohl irgend ein internes Flag (nicht) schleifen. ^^ |
|
| |
| |
| |
|
|
RGH | Hallo Jörg,
das liegt in diesem Fall daran, dass mit GetText$() immer nur das erste Feld der Statuszeile ausgelesen werden kann und da wird dann nur ein Parameter erwartet. (Siehe Aiuto zu GetText$())
Das Komma wird zwar von XProfan noch gelesen, aber nicht mehr der zweite Parameter. Und ein Komma nach einem Print bedeutet, mit dem nächsten Printbefehl in der gleichen Zeile mit einem Feld Abstand weiter zu machen. (Siehe Aiuto zu PRINT).
Einem genaueren Beobachter wäre bei der Ausgabe aufgefallen, dass bei der Ausgabe mit GetText$() immer nur der erste Eintrag der Statuszeile ausgegeben wird. ;)
Saluto
Roland |
|
| |
| 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 | 08.11.2011 ▲ |
|
| |
|
|
Jörg
Sellmeyer |
Einem genaueren Beobachter wäre bei der Ausgabe aufgefallen, dass bei der Ausgabe mit GetText$() immer nur der erste Eintrag der Statuszeile ausgegeben wird. ;)
Danke - ich kann mich auch mit was Anderem beschäftigen...
iFs Verweis zeigt aber, daß es eben nicht nur in diesem Fall passiert. Auch mir ist es schon in anderen Zusammenhängen aufgefallen. Im Moment habe ich leider kein Beispiel parat aber wenn ich was habe, poste ich es.
Wäre doch auf jeden Fall eine gute Gelegenheit GetText$() etwas aufzubohren. |
|
| |
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ... | 09.11.2011 ▲ |
|
| |
|
|
RGH | iFs Verweis muss ich mir noch mal ansehen.
Die Ergänzung von GetText$ auf die Statuszeile wäre sicher keine schlechte Idee, obwohl man ja wissen sollte, was man hineingeschrieben hat und es daher nicht abfragen muss. ;)
Aber zunächst geht es mir um reine Bugfixes und nicht um neue Features.
Saluto
Roland |
|
| |
| 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 | 09.11.2011 ▲ |
|
| |
|
|
Dieter
Zornow | | Ich benutze das oftmals um ein Verzeichnis und den Dateinamen sowie aktuelle Infos per Programm da abzulegen. Also weiß ich nicht was drin steht. Es gibt sicherlich noch tausend denkbare Möglichkeiten die Statuszeile per Programm zu nutzen. Wäre also absolut sinnvoll |
|
| |
| XProfan X2Er ist ein Mann wie ein Baum. Sie nennen ihn Bonsai., Win 7 32 bit und Win 7 64 bit, mit XProfan X2 | 09.11.2011 ▲ |
|
| |
|
|
Jörg
Sellmeyer | Das sehe ich wie Dieter: wenn ich eine Statuszeile einsetze, stehen da Dinge drin, die aktuell passieren. Es è ja Status- und nicht Statikzeile.  |
|
| |
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ... | 09.11.2011 ▲ |
|
| |
|
|
| Hoffentlich bedenkt ihr das andere Prozesse den Inhalt der Leiste wie auch z.B. Fenstertitel verändern können -
per den Programmablauf relevante Informationen würde ich nicht in solch Controls legen. ^^ |
|
| |
| |
| |
|
|
Dieter
Zornow | | Da befürchte ich gar nichts, denn welcher normale User kann das schon tun. Für Hacker oder Leute die sich besser auskennen und auf eine solche dumme Idee kommen, soll es halt so sein und das Programm stürzt vielleicht ab. Ja und ? |
|
| |
| XProfan X2Er ist ein Mann wie ein Baum. Sie nennen ihn Bonsai., Win 7 32 bit und Win 7 64 bit, mit XProfan X2 | 09.11.2011 ▲ |
|
| |
|
|
RGH | Dann erinnere man mich dran, wenn es um die nächste Version geht!
Saluto
Roland
(wird die kommenden 4 Tage brettspielend ohne PC im Sauerland verbringen) |
|
| |
| 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 | 09.11.2011 ▲ |
|
| |
|
| |
| |
| - Page 2 - |
|
|
Jörg
Sellmeyer | iF (09.11.11)
Hoffentlich bedenkt ihr das andere Prozesse den Inhalt der Leiste wie auch z.B. Fenstertitel verändern können -
per den Programmablauf relevante Informationen würde ich nicht in solch Controls legen. ^^
Da würd ich aber auch gern mal wissen, welcher Prozess das erlaubterweise macht.
Die Statuszeile ist doch dafür da, per den Nutzer relevante Infos anzuzeigen. In einem Editor z.B. in welcher Zeile er sich gerade è und an welcher Position in der Zeile. Oder in einem Dateitool, in welchem Ordner er gerade ist und, und, und |
|
| |
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ... | 09.11.2011 ▲ |
|
| |
|
|
| Ja, Mostra -
ich schrieb ja: "für den Programmablauf relevante Informationen" -
Infos die man "anzeigt" sind normal ja nicht per den Programmablauf relevant sondern erst wenn man diese Infos wieder abruft und Vorgänge davon abhängig macht.
So ungewöhnlich ist es übrigens garnicht das ein fremdprozess Titel ändert von sichtbaren Controls -
so gibt es Desktoptools die z.B. Fenstertitel ändern sobald der Mauszeiger drübersteht.
Es geht auch nicht um "hacken" wie darum um übers Netzwerk in ein System einzudringen sondern darum das man per den Programmablauf relevante Infos doch vlt. besser in Variablen ablegt statt in sichtbare Controls die wohlmöglich von anderen Prozessen einfachst geändert werden können.
Das "normale" Programmvariablen "auch" nicht sicher sind kann keine Diskussion sein da schon das OS nicht "sicher" ist. |
|
| |
| |
| |
|
(266)
Deutsch
English
Français
Español
Italia