Programm schlafenlegen unter Windows [Archiv] - ProgForum.com

Import-Script

04.05.2003, 21:40

Hab unter Win ein Programm BPW7.0 das alle Sekunde nur was tun soll und andere nicht behindern soll, d.h. die Kontrolle eine Zeitlang abgeben. StartZeit:=Gettickcount; repeat until Gettickcount > StartZeit+1000; das wärs, aber da beschäftigt das Programm den Rechner 100 Millionen mal mit Zeitabfrage, d.h. Fenster anderer Programme ruckeln. So eine Art Sleep(1 Sekunde) bräuchte ich. Weiss jemand was gutes?

Import-Script

04.05.2003, 22:32

In Java würde man hier "Thread.sleep(1000);" schreiben.

Import-Script

05.05.2003, 14:49

BPW7.0 sagt mir jetzt nichts. Mit der Timerfunktion in VB kann in bestimmten Intervallen eine Funktion aufgerufen werden. Durch DoEvents wird die Kontrolle an andere Tasks abgegeben. Siegfried

Import-Script

05.05.2003, 15:07

Das geht schon irgendwie mit Send_Message und Wait_Message, ich dachte nur einer wüsste auf die Schnelle wie... Übrigens BPW ist Borland Pascal für Windows, also die letzte Version "Turbo-Pascal" bevor Delphi kam. Hat halt den Vorteil, dass es gewohnt ist und die Turnarounds eben Turbo-like sind. Kommt ohne watztige Oberfläche, also wie Turbo-Pascal-DOS, dann nimmt man statt CRT Unit die WinCRT und pinselt mit Read und Write in ein logischerweise nicht sehr ansprechendes Textfenster. Etwas spartanisch, aber für meine Zwecke völlig ausreichend. Man muss halt so ein paar Windows-Spezifische Funktionen etwas entgegenkommender schreiben, sonst legt man den Rechner lahm. Also in alter DOS-Manier ASM ( SEI; irgendwas CLI ) dann hängt halt alles. Genauso wie bei repeat until soundsoviel Mikrosec. Dann ruckeln die anderen Applikationen. Aber für so ein bisschen Bastel-Port hin und her und paar Meldungen ist´s ausreichend.

Import-Script

27.05.2003, 21:07

in kernel32.dll ist die prozedur "sleep" exportiert. unter vb wärs also z.b.: Declare Sub Sleep Lib "kernel32" (ByVal dwMilliseconds As Long) das ist doch genau das, was du benötigst, nicht ?

Import-Script

28.05.2003, 20:45

Ehhhh, klasse!!! Danke!!!! Weiss zwar noch nicht, wie ichs hinkriege, aber das ist schonmal ein Anfang, auch an andere Windows-Schätzchen und Gemeinheiten heranzukommen.

Import-Script

31.05.2003, 16:28

Import-Script

01.06.2003, 13:16

Danke nochmals, das Applicartion.ProcessMessaages ist die Lösung. Leider ist der Kram sowas von beschissen dokumentiert, da gehts nur los "handle, h the handle in the wind"... und das ganze dann in C (trotz dass es ein Pascal Compiler ist), nullterminierte Strings und lauter so Gewurschtel; also irgendwie total am Compiler-User vorbei. Ich hab mir bis dato damit beholfen, dass ich in der while-Schleife getkey aufrufe oder den Cursor irhendwohin setze. Das wird wohl intern so gehandled, dass dann andere Programme auch zum Zug kommen.

Import-Script

01.06.2003, 15:48

Joa das ist die WinAPI, das schaut in fast jeder Sprache gleich aus... Aber ganz so heftig ist die Sache mit den DLLs dann nun auch wieder nicht, das DLL-Tutorial solltest du dir bei Interesse einmal durchlesen, ist alles relevante verständlich erklärt: <a href="http://assarbad.org/de/sources.shtml" target=_top>http://assarbad.org/de/sources.shtml</a>

Import-Script

02.06.2003, 18:48

Baaaaaaa......?????? und wo bleibt bei der ganzen Aktion der "Gelegenheitsprogrammierer", der nicht den ganzen Tag in Windows- und Compiler Interna wütet?, sondern "nur" ein Programm schreiben will? - ohne gleich Windows auseinanderzunehmen. Dazu mal ein kleines Beispiel: Ist jetzt absolut ernst gemeint: Normal-Programmierer schreibt: WRITE('BITTE DATEINAMEN EINGEBEN'); READLN(FILENAME); eigentlich ganz profan, nur heute auf den Mammut-BS(en) mit Filenamen "gigantisch" nicht mehr möglich. Jetzt erwarte ich doch, dass mir das BS genau diese Unterstützung gibt, z.B. so: FILENAME := (FILESELECTORBOX); Das sollte unter Windows, Linux, MAC, egal was, einfach diese Box einblenden, mit Listem, neuer Ordner usw. eben bis man dann OK drückt. Das Ganze ohne Schnörkel, also der Filename muss nicht mit Getöse von der Soundkarte auf einer Eisenbahn quer über den Bildschirm huschen. Standard Dialog. Wenn jetzt der Name dank Windows (oder MAC schon immer) natürlicxh bei der Aktion grösser als 254 Zeichen wird (PASCAL), dann definiere man doch auf den heutigen Rechnern String[nach belieben] also auf einem 32Bit Rechner mit 512Megabyte RAM : var FILENAME:STRING[50000]; {why not?} Benutze ich das a)falsche BS oder b)falsche Compiler? Windows - Free-Pascal / MAC - CodeWarrior9Gold Ich will doch nur ein saublöd einfaches a´la C64 Progrämmelchen, ohne gleich erschlagen zu werden...

Import-Script

03.06.2003, 10:01

Da hat er Recht ... Bei der FileSelectBox hat man ja auch noch einen Miniexplorer dabei, ein Teil das auf File-Vorhanden untersucht, Scrolbalken, Dateifilter, ein paar Knöpfe usw. Überigens: DIM strName as String INPUT "Bitte Dateinamen eingeben"; strName OPEN strName FOR OUTPUT AS #1 ging bis vor kurzem noch in QBasic, sogar unter 95, und NT. Bei 98, 2000 und XP bin ich mir da nicht sicher. Siegfried

Import-Script

03.06.2003, 10:23

Qbasic geht unter 2000 <img src="http://progshop.com/elektronik/diskussion/clipart/biggrin.gif" border=0> Ist zur Zeit meine Aufgabe, solche Saurier auf Java umzuschreiben.

Import-Script

03.06.2003, 12:17

Wieso Saurier? QBasic geht wenigstens noch auf eine Diskette drauf. Andere Frage: Wieso umschreiben? Dann kann man doch gleich Java programmieren. Hätten die Softwerker nicht innerhalb eines Jahres 10 Dialekte und 20 verschiedene und 30 verschiedene und 40..... - also Java mal Java gelassen und für den Otto-Normalverbraucher zurechtgestutzt; ich war hellauf begeistert, als ich von der Java-Idee gehört habe, wäre fast umgestiegen, aber dann kamen die Saurier!!!

Import-Script

03.06.2003, 12:43

Och, Java-Programme gehen schon auch schön auf Diskette drauf... wenn man die VM schon hat... Ansonsten kann man ja Memory Stick nehmen... Ach übrigens: Diskette = auch Saurier <img src="http://progshop.com/elektronik/diskussion/clipart/lol.gif" border=0> , am Aussterben. Umschreiben(eben auf Java) deswegen, weil keiner mehr richtig Ahnung hat, wie das Ding eigentlich funktioniert. Muß ja froh sein, daß überhaupt noch Quellcode da ist. Das ist dann eben "Fortschritt". Modernere Systeme erfordern modernere Programmiertools. Mit dem alten Zeug will sich kein Entwickler mehr rumärgern. Wenn man eben mal den "Bildschirmaufbau" von Qbasic und Java vergleicht, kann man nur sagen Qbasic - Bäääääh!

Import-Script

03.06.2003, 15:08

dann schau dir doch mal den speicherverbrauch an. und qbasic kann man (mit etwas viel gutem willen) auch mit assembler kombinieren. und auch sonst kriegt man hübsche grafiken hin...

Import-Script

03.06.2003, 16:49

Ja, 15MB für etwas simples taschenrechnerähnliches sind schon heftig...(hat man aber schnell reigeholt wenn man den unnützen Krampf aus der Statusleiste rausholt ;)) Dafür bekommt man aber mit einem Programm Linux, Apple, Windows (und ein paar unbedeutende) unter einen Deckel(so ziemlich). C++ ist da nicht so speicherhungrig. Java ist ja noch nicht in einem Endzustand, sondern wird ständig verbessert, mal sehen was draus wird. Wenn du natürlich so viel Zeit hast, dich mit QBasic abzuquälen, bitte. Wird aber immer schwieriger werden, die Programme zum Laufen zu bringen. Die "Entwicklungsumgebung" ist auf keinen Fall mehr zeitgemäß. Die Benutzung auch nicht mehr. (mal ganz abgesehen von "Spaghetticode macht Freude") Assembler: - Zur Steuerung von Hardware: Die NT-Betriebssysteme lassen das schon nicht mehr zu, einfach steuerbare Hardware wird auch immer seltener. - für schnelle Programme: In C (wahrscheinlich auch C++) kann man noch viel einfacher Assembler integrieren. Assembler macht auch nur solange Sinn, wie der Programmierer sein Programm überblicken kann. (Wer programmiert heutzutage unter Windows noch Assembler??)(böse Professoren behaupten ja, C sei nichts weiter als besserer Assembler, keinesfalls eine Hoch-programmier-sprache)

Import-Script

03.06.2003, 22:19

Lange Zeit ist der Thread nun offen, will jetzt auch meinen Senf dazugeben: Zum eigentlichen Thema: 1. Assembler ist immer nützlich, egal in welcher Sprache!!! 2. Eine "einfachere" Sprache zum Einstieg kann nicht schaden (VB; QBasic, etc.) 3. C/C++/C# ist dann auf jeden Fall zu empfehlen, wen du kommerziel was machen willst, oder einfach nur den "puren" Windows Style raushängen mags. Ob ihrs glaubt oder nicht, auch heute wird noch oft Assembler in C++ integriert!!! Ich kenne diverse Leutz die DirectX 8/9 bunt über ASMs ansteuern, weils sie meinen das wär schneller (stimmt vieleicht?); auf jeden Fall ist es kleiner; Quellcodes von Demos die DirectX nutzen beinhalten meißtens Asm {...} Statements in Hülle und Fülle. Hier poste ich noch ein kleines Beispiel meiner C++ Windows Kunst...für Abstürze oder Datenverluste oder was auch immer wird KEINE Verantwortung übernommen; Benutzung auf eigene Gefahr!!! Aber: Nur Mut! JEDER (na gut, FAST jeder ;) kann sowas schreiben, sind ja nur 6149 Zeilen Quellcode (Kommentare NICHT mitgezählt!) Ach ja: Beide Dateien in EIN Verzeichnis extrahieren und "Enjoy!" <center><table border=1><tr><td><img src="http://progshop.com/elektronik/diskussion/icons/mime_zip.gif" align=left alt="application/x-zip-compressed">Proggy <a href="http://progshop.com/elektronik/diskussion/messages/4285/TheEdit-7386.zip" target="_blank">TheEdit.zip</a> (220.9 k)</td></tr></table></center>

Import-Script

05.06.2003, 12:19

zum thema hardware-steuern/winnt: ein weit verbreiteter irrglaube. man kann auch unter nt noch so ziemlich alles ansteuern. nur was nicht bekannt ist, wird nicht zugelassen. aber z.b. die grafikkarte kann man ganz schön verwursteln, dasselbe gilt für parallel/seriell-ports. was geschützt wird, ist z.b. der speicher. zum thema "Spaghetticode macht Freude": da stimme ich dir nur halb zu. auch mit qb ist es möglich einigermassen strukturierte programme zu schreiben. es kommt halt auf den programmierer/das programmdesign an. mit c/c++ kann man (meiner meinung nach) viiieeeel mehr rumwursteln und unleserlichen code schreiben. aber pascal ist sowieso am besten :-) >Wer programmiert heutzutage unter Windows noch Assembler?? z.b. <a href="http://grc.com" target="_blank">http://grc.com</a> nur mal so zum bedenken: c/c++ ist in meinen augen nicht der weisheit letzter schluss. ich halte die beiden sprachen für hack-sprachen, also eigentlich ungeeignet, um programme zu schreiben. dazu kommt wie windows-api welche im vergliech z.b. zu beos oder qnx wirklich amateurhaft erscheint. richtig schön wird programmieren mit freepascal unter beos.

Import-Script

05.06.2003, 14:55

Hehe, was lese ich da? BE-OS??? Also ich als Pascal-Verfechter und auch Basic-Gerne-Benutzer stimme da absolut zu. Jetzt machts mich doch umso neugieriger, wenn ich höre Free-Pascal unter BE-OS. Ich hab mit dem Gedanken gespielt, BE-OS zu benutzen, aber die Zeta-Leute wollen wohl nichts verkaufen, jedenfalls nicht so wirklich; eine Anfrage meinerseits blieb bis dato unbeantwortet. Lieber Doktor Teufel, wenn Du da Infos zu hast, schick einem mittlerweile programmiertechnisch zum Masochisten gewordenen, extrem suizidgefährdeten "unter Windows und MAC Pascaler" doch mal eine Mail. Vielleicht kannst Du ein Leben retten - oder mich komplett zum Programmiersatan machen. Nur über die Folgen sei Dir dann bewusst... <a href="mailto:A.Seck@T-online.de">A.Seck@T-online.de</a><img src="http://progshop.com/elektronik/diskussion/clipart/uhoh.gif" border=0>

Import-Script

05.06.2003, 18:20

Also nun blick ich nicht mehr durch: "Kann man unter Windows mit C, Turbo-C und C++ denn nun Hardware über z. B. Parallel-Port und Serieellen-Port ansteuern oder nicht???" Gruß Winnie

Import-Script

05.06.2003, 20:16

@Wiennie: Ja klar, man kann! Wenn es nicht direkt geht, findet man im I-Net leicht Libaries in dll-Form die das können (AUCH unter NT). Meißt reicht es aber die C-Funktion Out(Port als HEX, bytes) oder so ähnlich zu benutzen.

Import-Script

05.06.2003, 22:31

Qbasic: Soweit ich in Erinnerung habe kann man unter NT die serielle Schnittstelle großteils problemlos ansprechen, die parallele nur über den dazugehörigen Softwareinterrupt. Keine vollständige Kontrolle. Wenn ich jetzt an meine selbermach-ISA-Karte ran will -> keine Chance. Mit Visual C/++: Serielle Schnittstelle ansteuern geht problemlos. Funktioniert mit File-Befehlen, nur das keine Datei aufgemacht wird, sondern ein Gerät. Zur seriellen Schnittstelle habe ich ein doch recht stattliches Demoprogramm von Microsoft samt Quellcode(VC), 166 kB in zip. Bei Parallelport ist es nicht so einfach, man kann zwar Daten über die 8bits nach außen schicken, aber auf die anderen Leitungen hat man keinen Zugriff. Müsste man Treiber dafür schreiben. Oder runterladen. Direktzugriff über in / out lassen die NT-Betriebssysteme nicht zu, ist auch keine saubere Lösung(Chaos wenn mehrere Programme die gleiche Schnittstelle verwenden wollen). Dieser FTDI-USB-Chip 245 könnte eine recht gute Lösung sein(virtueller COM-Port), der sich dann wieder mit den File-Befehlen ansprechen lässt. Habe aber noch überhaupt nicht in dieser Richtung experimentiert.

Import-Script

06.06.2003, 09:44

Ganz locker wirds mit Karten, von denen der PC nichts weiss. Was er nicht weiss, macht ihn nicht heiss... Solange man ihm nicht seine eingenen Schnittstellen und Interna durcheinanderbringt hat wohl keiner (auch ein Betriebssystem) etwas dagegen, an Hardware rumzuprogrammieren. NT und Konsorten mögen es nur nicht, dass man den "User-Mode" hintergeht. Dto. Unixe; man braucht also für diese Operation Supervisor-Rechte, und die kann man sich holen bzw. selbst geben. Unter Win 95,98 etc. gibts überhaupt keinen Ärger, solange man nicht gerade die LPT1 für Prommer, Drucker, und Funkmodem und und und benutzt. Nur, was solls, wer macht das schon? Ich habe mir eine 0815 2fach Parallelport Karte dazugesteckt (Adressen halt jenseits von 3BC,378,278), ohne IRQ ohne DMA ohne ohne... und fertig. Der Gerätemanager von 98 zeigt sie auch nicht an. Gut so, sei mir nur Recht. Wenn ich will, dass er es weiss, dann erzähle ich es ihm schon. ICH!!! und nicht dieser blöde Hardwareassistent. Darauf greife ich mit Port-Befehlen zu, respektive in Free-Pascal mit Assembler-Äquivalenten. Dagegen gibt es doch nichts einzuwenden und "unsauber" ist das auch nicht. Ich betreibe ein Gerät XY mit einer Interfacekarte XY und einer zugehörenden Software XY. Das ist doch OK.

Import-Script

06.06.2003, 10:33

In einer Rechnerumgebung, wo nur eine Anwendung läuft, spricht auch überhaupt nichts dagegen. Allerdings wollten die gierigen Anwender alles gleichzeitig auf ihren Kisten haben. Das war dann halt die Geburtsstunde der sog. Multitasking-Betriebssystem, früher noch QEMM und Konsorten. Später kann dann auch noch Windows dazu. Hier machts ja auch Sinn, das nicht jede Anwendung an der Mouse rumzieht, jede Anwendung am Drucker rumdruckt, und der Bildschirm etwas geordnet aufgebaut ist. Da muss es im inneren des BS etwas bürokratischer zugehen, sonst könnte man die Vorzüge solcher Betriebssysteme gar nicht nutzen. Ihr habt es so gewollt. Siegfried

Import-Script

01.10.2003, 13:49

Das hier habe ich grad in einem älteren Programm von mir gefunden, sollte genau das tun was du willst, Andreas: procedure Wait(Time: LongInt); var Start : LongInt; begin Start := GetTickCount; while (GetTickCount < Start + Time) do Application.ProcessMessages; end;<img src="http://progshop.com/elektronik/diskussion/clipart/smile.gif" border=0> das zur Erinnerung, kam von Sascha, läuft leider unter Free-Pascal nicht so. An die Windows Funktionen heranzukommen ist und bleibt ein Buch mit Sieben Siegeln oder Compilervergewaltigung oder oder oder; Echt Dreck, dass die ihre Hausaufgaben nicht machen; das Thema hätte die interne DELAY-Funktion von Haus aus erschlagen müssen. Nun gut, es geht anders: var Dummy:char; Schleife mit Tickcount, ob "Repeat until" oder "While" ziemlich egal, ein DUMMY := Readkey; in der Schleife tut es sauber hoch drei. Wie es scheint verbirgt sich in der Funktion eben dieser Process-Messages Aufruf; und es läuft sauberst - mein Programm während ich hier batronixe; kein Thema; kooperativ ohne Ende. Ich kann auch keinerlei negative Auswirkungen feststellen; selbst Musik hören geht zusätzlich nebenbei während mein Akkulader seine Grafik plottet und ich dies hier schreibe. WIN98 wohlgemerkt, nicht NT, da geht´s (sollte es) ohne solche Tricks. Werd ich demnächst mal testen...<img src="http://progshop.com/elektronik/diskussion/clipart/smile.gif" border=0> Nur als kleines Feedback mal.

Import-Script

14.10.2003, 12:05

Die sache mit den "processmessages" ist in Ordnung. Allerdings sollte man beachten, dass das Programm dann immer noch beachtlich Taktzyklen "verbraucht". Es gibt noch die Möglichkeit, sich eine ISR auf dem Timer Interrupt zu schreiben. Ich selbst arbeite mit Delphi. Dort gibt es zB auch ein "Timer-Objekt" (weiss nicht, ob es sowas auch unter BPW gibt).

Import-Script

17.10.2003, 11:23

Das ist genau mein Problem: Ich will diesen Objekt-Rotz nicht. An Sachen wie TimerINT-Routine hatte ich auch schon gedacht, am liebsten wäre es mir sogar, direkt an den Uhrenchip zu gehen und dem "den Wecker zu stellen". Leider scheitert das dann mit der Portabilität auf andere Rechner, die keinen Wecker-Uhrenchip haben.<img src="http://progshop.com/elektronik/diskussion/clipart/smile.gif" border=0>