Hallo Forengemeinde,
möchte per VBA / mscomm32.ocx auf die RS232 zugreifen. Leider kommt hier
bei meinem Minimal-Programm der Fehler "Objekt erforderlich"
Es fehlt anscheinend das Setting zu: MSComm1.
Und da weiß ich nicht, was da fehlt. Recherche habe ich unter mehreren
VBA-Foren gemacht. Codes sind identisch. Im Objektkatalog ist es
vorhanden.
mein Code:
Control registriert (regsrv32) und lizenziert?
Das Teil will einen Lizenzschlüssel in der Registry, entsprechende Keys
sind glücklicherweise im Internet leicht auffindbar.
Solang du nur bei dir privat damit rummachst, wird da auch kein Hahn
danach krähen.
Die MsComm-Dll habe ich selber leider nicht.
Es sieht so aus, als hättest Du das Objekt MsComm1 nicht deklariert bzw
erzeugt.
In meinem uralten Office 2000 gibt es im VBA-Editor (ALT F11) den
Menüeintrag Extras mit der Auswahlmöglichkeit "Verweise".
Da muss das Control vorhanden sein und das Häkchen zur Aktivierung
gesetzt.
In allen Beispielen, die ich bisher gesehen habe, bestand das Objekt aus
einem Formular, das MsComm-Eigenschaften hatte, wie z.B. hier:
https://www.ontrak.net/visual.htm
Du siehst das an dem Bild, das unterhalb des Texts
[...
The MSComm properties allow the setting of communication parameters
including port selection and port enabling functions.
...]
steht.
https://www.tek-tips.com/viewthread.cfm?qid=585370
Wenn man das Objekt nicht über VBA-Code zugänglich machen kann, müsstest
Du Unter Office 2000 mit dem Menüeintrag "Einfügen", dann "Objekt" eine
neue Instanz dieses Objekts erzeugen. Ich weiß nicht, wo sich das im
aktuellen Excel-Menüs versteckt.
Thomas S. schrieb:> möchte per VBA / mscomm32.ocx auf die RS232 zugreifen. Leider kommt hier> bei meinem Minimal-Programm der Fehler "Objekt erforderlich"> Es fehlt anscheinend das Setting zu: MSComm1.>> Und da weiß ich nicht, was da fehlt.
Das Objekt halt, steht doch ausdrücklich und sogar auf deutsch da.
> Im Objektkatalog ist es> vorhanden.
Im Katalog stehen nur die COM-Klassen, die man (evtl.) instanziieren
könnte. Du musst das Teil auf die Form oder das Tabellenblatt oder was
auch immer ziehen. Erst dadurch entsteht eine Instanz, also das
benutzbare Objekt.
Peter M. schrieb:> Du siehst das an dem Bild, das unterhalb des Texts
Das habe ich mir angeschaut. Soweit komme ich aer nicht.
Ich kann unter Visual Studio 6, das ich hier habe, das Telefon nirgends
finden. in Access2000 / VB habe ich dieses gefunden.
Verweis ist erstellt, mit MScomm32.ocx
Ob S. schrieb:> Du musst das Teil auf die Form oder das Tabellenblatt oder was> auch immer ziehen. Erst dadurch entsteht eine Instanz, also das> benutzbare Objekt.
Das finde ich eben nicht. Bitte erkläre mir dass.
Hallo Thomas S.,
Thomas S. schrieb:> Peter M. schrieb:>> Du siehst das an dem Bild, das unterhalb des Texts>> Das habe ich mir angeschaut. Soweit komme ich aer nicht.> Ich kann unter Visual Studio 6, das ich hier habe, das Telefon nirgends> finden. in Access2000 / VB habe ich dieses gefunden.
Du sprachst in Deinem Auftaktbeitrag von VBA ("Visual Studio for
Applications"). Das ist ein abgespecktes VB, von dem ich ausgehe, dass
Du es unter Microsoft Excel nutzt.
Bitte stelle klar, wo Du "das Control" nutzen willst.
Thomas S. schrieb:> Peter M. schrieb:>> Du siehst das an dem Bild, das unterhalb des Texts>> Das habe ich mir angeschaut. Soweit komme ich aer nicht.> Ich kann unter Visual Studio 6, das ich hier habe, das Telefon nirgends> finden. in Access2000 / VB habe ich dieses gefunden.>> Verweis ist erstellt, mit MScomm32.ocx
Hast Du unter Projekt -> Komponenten -> Microsoft Comm 6.0 (SP6) die
MSComm32.OCX zum Projekt hinzugefuegt?
Dann kannst Du ein Objekt hinzufuegen.
Es kann auch sein, dass Du mindestens die Professional-Version
installiert haben solltest (Gedaechtnis ist etwas fuzzy, ist 25 Jahre
her. MS hatte damals die "Business"-Funktionen nur gegen mehr Muenzen
freigeschaltet. Aber, dass ist alle Fuzzy).
Thomas S. schrieb:> Peter M. schrieb:>> Du siehst das an dem Bild, das unterhalb des Texts>> Das habe ich mir angeschaut. Soweit komme ich aer nicht.> Ich kann unter Visual Studio 6, das ich hier habe, das Telefon nirgends> finden. in Access2000 / VB habe ich dieses gefunden.>> Verweis ist erstellt, mit MScomm32.ocx>> Ob S. schrieb:>> Du musst das Teil auf die Form oder das Tabellenblatt oder was>> auch immer ziehen. Erst dadurch entsteht eine Instanz, also das>> benutzbare Objekt.>> Das finde ich eben nicht. Bitte erkläre mir dass.
Mal auf Icon mit "OLE" klicken. Geht eine Liste der verfügbaren
COM-Objekte auf. Eins davon müsste irgendwie nach MSCOMM aussehen. Ich
kann mich leider nicht mehr erinnern, unter welchem Namen das genau
auftaucht.
Übrigens sieht sein Screenshot nicht wirklich nach Access2000-VBA aus.
Das sieht eher nach VB5 oder VB6 aus.
Peter M. schrieb:> Du sprachst in Deinem Auftaktbeitrag von VBA ("Visual Studio for> Applications"). Das ist ein abgespecktes VB, von dem ich ausgehe, dass> Du es unter Microsoft Excel nutzt
Nein ich habe hier Visual Studio 6 Prof.
Und möchte damit auf die Serielle Schnittstelle zugreifen.
Thomas W. schrieb:> Hast Du unter Projekt -> Komponenten -> Microsoft Comm 6.0 (SP6) die> MSComm32.OCX zum Projekt hinzugefuegt
Das geht nicht. Da kommt die Fehlermeldung : Name steht in Konflikt mit
vorhandenem Modul, Projekt oder vorhandener Objektbibliothek.
Die MSComm.Lib steht im Objektkatalog drin. Und darin sind die
Funktionen für die Serielle.
Thomas S. schrieb:> Nein ich habe hier Visual Studio 6 Prof.
Dach't ich's doch. Also hast du schonmal Müll erzählt. Es geht
offensichtlich überhaupt nicht um VBA, sondern um VB. Falls du es nicht
weißt: Das ist ein erheblicher Unterschied.
> Das geht nicht. Da kommt die Fehlermeldung : Name steht in Konflikt mit> vorhandenem Modul, Projekt oder vorhandener Objektbibliothek.
Ist also schon eingebunden (was bei einer standardmäßigen
VB6-Installation ja auch der Normalfall wäre). Also: ist bloß noch nicht
für dein Projekt instanziiert.
> Die MSComm.Lib steht im Objektkatalog drin. Und darin sind die> Funktionen für die Serielle.
Nochmal zum Nachbeten: Da steht drinne, was die Klasse kann. Damit du
diese Sachen verwenden kannst, musst du die Klasse instanziieren, also
ein Objekt erzeugen.
Ob S. schrieb:> Falls du es nicht> weißt: Das ist ein erheblicher Unterschied.
Okay, danke für die Darstellung.
Ob S. schrieb:> Nochmal zum Nachbeten: Da steht drinne, was die Klasse kann. Damit du> diese Sachen verwenden kannst, musst du die Klasse instanziieren, also> ein Objekt erzeugen.
Bitte erkläre nun, wie das nun ansprechen kann.
Zwischenzeitlich war ich in Access, und dort in VBA. Von dort aus konnte
ich, nachdem das Telefon im Formular war, und ich noch etwas, wie den
Namen, MSComm1 hier eingefügt hatte, die Serielle ansprechen. War meine
PCMCIA Karte micht drin, hat VBA gemeckert, war sie gesteckt, ging die
Routine ohne meckern durch.
Aber nochmal. Ich bin hiermit nicht so routiniert, bitte um Erklärung,
wie ich dies instanzieren kann, oder eben auch das Telefon auf das
Formular bekomme. DANKE
Hallo Thomas S.,
Ob S. schrieb:>> Die MSComm.Lib steht im Objektkatalog drin. Und darin sind die>> Funktionen für die Serielle.
unter Excel 2000 musste ich im VBA-Editor (ALT F11) auf
Menüleiste/Extras/Zusätzliche Steuerelemente gehen und dann aus der
Liste aller verfügbarer Steuerelemente das MSComm-OCX auswählen.
Dann erschien in der Steuerelemente-Toolbox ein Telefonsymbol.
Dieses habe ich per "Drag-n-Drop" in das Formularfenster gezogen.
Wenn ich das Telefonsymbol anklicke, erscheint im Eigenschaftenfenster
der Name dieses MSComm-Objektes und seine Eigenschaften.
"Visual Studio 6 Prof." ist eine Entwicklungsumgebung mit mehreren
Sprachen. Du solltest vielleicht mal explizit sagen, welche Sprache Du
benutzt. Ist es Visual Basic, dann solltest Du analog zur Vorgehensweise
in VBA für Excel im VB-Editor das MSComm-Objekt auswählen, so dass sein
Symbol in der Steuerelemente-Toolbox erscheint.
Dann solltest Du es analog zur Vorgehensweise oben in Dein
Benutzerformular "User form" ziehen können.
Tust Du das nicht hilft der kopierte Code von ganz oben nicht weiter,
weil keine Instanz ("Exemplar") Deines MSComm-Objektes vorhanden ist.
Ich kann Dir leider nicht sagen, ob es möglich ist, auch ganz ohne "User
form" dieses Objekt anzulegen.
Peter M. schrieb:> "Visual Studio 6 Prof." ist eine Entwicklungsumgebung mit mehreren> Sprachen.
Dort versuche ich es unter Visual Basic 6.0
Das Telefonsymbol schaffe ich ja unter VBA in Access zu installieren.
Aber eben nicht in Basic unter dem Studio. Da benötige ich Hilfe. Habe
das aber onen schon geschrieben. Ein Screenshoot ist oben in meinen
Posts auch bereit sichtbar.
Hallo Thomas S.,
Ob S. schrieb:> Mal auf Icon mit "OLE" klicken. Geht eine Liste der verfügbaren> COM-Objekte auf. Eins davon müsste irgendwie nach MSCOMM aussehen. Ich> kann mich leider nicht mehr erinnern, unter welchem Namen das genau> auftaucht.
was ist das Ergebnis?
Ich habe Dir auch erklärt, wo Du suchen könntest. Ich hätte erwartest,
dass Du jetzt berichtest, wo Du gesucht hast und was das Ergebnis war.
Deine Bitte um Hilfe funktioniert nicht - ich habe kein VB6. Du musst
jetzt selber suchen gehen.
Peter M. schrieb:> Ob S. schrieb:>> Mal auf Icon mit "OLE" klicken. Geht eine Liste der verfügbaren>> COM-Objekte auf.
Wenn Du das OLE links, unter Allgemein meinst? - Da geht dann ein
Fenster auf, worin ich Adobe, oder sonstwas als OlE auf dem Formular
plazieren könnte. Aber nicht das Telefon.
Ich schrieb oben die Fehlermeldung. Hänge diese hier als Screenshoot
dran.
Es sieht so aus, als hättest Du das OCX durch Nachinstallation jetzt
zweimal im System.
Mach mal die beiden Häkchen weg, wann verschwindet die Fehlermeldung?
Suche dann auf dem Reiter "Designer" und "einfügbare Objekte" nach dem
Symbol. Falls nicht vorhanden, weitersuchen wie oben bei mir
beschrieben.
Comm Control <> Common Control!
Was fuer ein Betruebssystem benutzt Du? Ich habe ein alten
WindowsXP-Laptop, Windows XP mit ServicePack 2. Die IDE laesst sich
nicht mehr unter Windows7 oder spaeter installieren.
Noch ein kleiner Hinweis: Visual Studio 6 laeuft dann, und nur dann
stabil, wenn Du Visual Studio 6 Service Pack 6(!) benutzt. Dein SP3 ist,
in a Nutshell, schlecht.
Ich habe noch mal meine Virtuelle Maschine gestartet (Windows XP SP 3,
2GB RAM, emulierter serieller Port, Visual Studio 6 (German) SP6,
\Windows\system32\mscomm32.OXC ist vom 16-JUN-2010, Version 6.01.9816,
119616Bytes gross, kommt alles aus Visual Studio 6 SP6):
Funktioniert wie geplant: Ich kann "Das Telefon" anklickern, in ein Form
packen und habe dann das automatische generierte MSComm1-Objekt (auf-
und zumachen geht, mehr kann ich nicht, dass Ding virtuell).
Wenn Du jetzt das erste Mal mit Visual Studio arbeitest: Das Drag & Drop
ist anderser: Du Clickst auf (z.b. command-Button) (Das Icon sinkt ein,
es sieht "gedrueckt" aus). Du musst dann zu einem Form mausen und ein
Recheck mit der Maus markieren: Dann bekommst Du ein Button in der
gewuenschten Groesse. Solange Du kein Rechteck gewaehlt hast, bekommst
Du das ausgegraute "No".
Aber richtig Stabil laeuft das alles ab Service Pack 6.
Thomas W. schrieb:> \Windows\system32\mscomm32.OXC ist vom 16-JUN-2010, Version 6.01.9816,> 119616Bytes gross, kommt alles aus Visual Studio 6 SP6):
Zugegeben. Meine Version ist älter. Ca. 98. Version:6.00.8169 vom 24.
Juni 1998,
Geht das nun trotzdem, zum laufen zu bringen?
Hallo Thomas S.,
mangels qualifizierter Rückmeldungen von Dir kann ich Dir nicht mehr
weiterhelfen.
Zwei Leute stellen Dir Fragen, die Du einfach ignorierst.
Kauf Dir einfach die Adontec-Supercom-Bibliothek für schlappe €260.
Viel Erfolg!
Thomas S. schrieb:> Thomas W. schrieb:>> \Windows\system32\mscomm32.OXC ist vom 16-JUN-2010, Version 6.01.9816,>> 119616Bytes gross, kommt alles aus Visual Studio 6 SP6):>> Zugegeben. Meine Version ist älter. Ca. 98. Version:6.00.8169 vom 24.> Juni 1998,
Warum willst Du nicht updaten? Falls ich mich richtig erinnere war
Visual Studio 6 SP3 richtig schlecht.
Ich weiss nicht, ob Visual Studio 6 Service Pack 6 (German) noch frei
verfuegbar ist (falls nicht, Muenzeinwurf bei MS hilft).
Gruesse
Peter M. schrieb:> mangels qualifizierter Rückmeldungen von Dir kann ich Dir nicht mehr> weiterhelfen.> Zwei Leute stellen Dir Fragen, die Du einfach ignorierst.
A: Ich habe Feddback gegeben.
Ivh habe gestern um 20:02 geschrieben.
Euer Feddback kam um
Thomas S. schrieb:> Zugegeben. Meine Version ist älter. Ca. 98. Version:6.00.8169 vom 24.> Juni 1998,> Geht das nun trotzdem, zum laufen zu bringen?
Darauf hin kam :
21:43 ein Post
und um
21:48 ein Post
Dann war nacht, und heute liege ich krank / flach - okay
Harald K. schrieb:> Warum um alles in der Welt will man damit im Jahr 2024 noch etwas> anfangen?
Ich möchte nur ein paar kleine Sachen per RS232 erledigen, und da würde
es mir reichen.
Peter M. schrieb:> Kauf Dir einfach die Adontec-Supercom-Bibliothek für schlappe €260.
Ist dass die 'professionelle' Antwort in einem Forum?
NEIN
Thomas W. schrieb:> Warum willst Du nicht updaten? Falls ich mich richtig erinnere war> Visual Studio 6 SP3 richtig schlecht.
Wo erkenne ich die SP-Version? - Unter Info sehe ich da nix.
SP6, aber englisch habe ich hier als 7z. Gäbe es auch eine deutsche
Version?
Hallo Thomas S.,
Thomas S. schrieb:> Peter M. schrieb:>> mangels qualifizierter Rückmeldungen von Dir kann ich Dir nicht mehr>> weiterhelfen.>> Zwei Leute stellen Dir Fragen, die Du einfach ignorierst.>> A: Ich habe Feddback gegeben.
Zu meinem Beitrag vom 1.8.2024 22:17 aber nicht.
Was ich von Dir erwartet habe: Eine Antwort auf meine Frage und eine
Ergebnismeldung zu meinen Suchvorschlägen.
> Ivh habe gestern um 20:02 geschrieben.
Aber nicht zu meinem Beitrag.
> Peter M. schrieb:>> Kauf Dir einfach die Adontec-Supercom-Bibliothek für schlappe €260.>> Ist dass die 'professionelle' Antwort in einem Forum?> NEIN
Auf jeden Fall. Stocher' mal schön weiter unsystematisch im Nebel herum
und stelle immer wieder neue Fragen und verprelle die, die Dir helfen
wollen.
Meine Kaufempfehlung ist passgenau zu Deinem Verhalten. Man kann Dir so
nicht helfen. Deine unstrukturierte Vorgehensweise verhindert Dein und
mein Erfolgsgefühl.
Thomas S. schrieb:> Thomas W. schrieb:>> Warum willst Du nicht updaten? Falls ich mich richtig erinnere war>> Visual Studio 6 SP3 richtig schlecht.
Frage nicht beantwortet. Betruebssystem, SP-Level?
> Wo erkenne ich die SP-Version? - Unter Info sehe ich da nix.
? -> Info -> Microsoft Visual Basic 6.0 (SP6)
Ich klinke mich jetzt aus. Kennst Du das Idom "like nailing jelly to a
tree"?
Peter M. schrieb:> Es sieht so aus, als hättest Du das OCX durch Nachinstallation jetzt> zweimal im System.> Mach mal die beiden Häkchen weg, wann verschwindet die Fehlermeldung?
Das hatte ich gesucht, aber wo sollte es noch sein? Da sind keine
Häkelchen mehr.
Habe 3 Screenshoots angefügt. In Verweise sind nur die oberen 4
angehakelt. Der Rest der Liste ist ohne. Auch an der zu erwartenden
Stelle von MScomm32.ocx ist nichts. Dies musste ich erst per Suche
hinzufügen, Aber dann kommt in Komponenten eben, dass es 2 mal da wäre.
Peter M. schrieb:> Meine Kaufempfehlung ist passgenau zu Deinem Verhalten. Man kann Dir so> nicht helfen.
Ich versuche hier wirklich die Teile zu liefern, um zur Lösung zu
kommen. Kann sein, dass Du hier mehr drauf hast, aber deshalb gibt es
das Forum, und deshalb frage ich hier.
Ich habs gefunden. Jabadu.
Folgendes war
In meinem bereits bestehenden Minimal Progrämmchen ließ sich das nicht
installieren, Inizieren.
Habe nun ein neues leeres Projekt eröffnet. Und dort gleich unter
'Komponenten' das Microsoft Comm Control 6.0 angehakelt.
Dann war das Telefon nun in der Galerie.
Kannst Du mir bitte erklären, was in den anderen Projekten dann 'schräg'
war, dass es nicht ging.
Thomas S. schrieb:> kommen. Kann sein, dass Du hier mehr drauf hast, aber deshalb gibt es> das Forum, und deshalb frage ich hier.
Ich habe hier gar nichts "mehr drauf" und muss Dich daher fragen, an
bestimmten Stellen zu gucken!
Ich habe Dir am 1.8.2023 um 21:10 detailliert beschreiben, wie ich das
MSComm-OCX unter Excel lauffähig gemacht habe, damit Du analog in Deiner
VB6-Umgebung nachsuchst. Das habe ich Dir aber nicht explizit aufgegeben
sondern erwartet.
Du hast am 31.7.2024 ein Bild des Form-Editor aus VB6/Visual Basic
gezeigt. Dort steht auch ein Menüeintrag "Extras".
Hier hättest Du nach Lektüre meines Beitrags nachsuchen sollen - habe
ich aber nicht gesagt.
Ich vermute, dass VB6 ohne aktivierte Verweise nicht auskommt.
Peter M. schrieb:> Es sieht so aus, als hättest Du das OCX durch Nachinstallation jetzt
Wo ist Deine Rückmeldung zum Thema Nachinstallation?
Auch "ich weiß nicht, ob" hätte ich akzeptiert.
Such das vermaledei
> zweimal im System.> Mach mal die beiden Häkchen weg, wann verschwindet die Fehlermeldung?
Wo ist die Antwort auf meine Frage?
Beide Häkchen löschen, melden, bei welchem Häkchensetzen der Fehler
auftritt! Die Common-Dialogue-OCX brauchst Du für serielle Kommunikation
nicht.
Thomas W. hat Dich übrigens jetzt zum zweiten Mal gefragt, welches
Betriebssystem Du nutzt. :( Au weia!
Such Deine MSComm32.OCX auf Deinen Laufwerken. Ist die bei verschiedenen
Softwareprodukten (in verschiedenen Ordnern vorhanden)?
Peter M. schrieb:> Ich vermute, dass VB6 ohne aktivierte Verweise nicht auskommt.
Ich habe es doch nun gefunden.
Peter M. schrieb:> Thomas W. hat Dich übrigens jetzt zum zweiten Mal gefragt, welches> Betriebssystem Du nutzt. :( Au weia!
Wusste nicht dass die von Relevanz ist. Ich bin hier auf XP unterwegs.
Kann aber beim Booten auswählen : XP/ Win7 / Suse Linux
Peter M. schrieb:> Such Deine MSComm32.OCX auf Deinen Laufwerken. Ist die bei verschiedenen> Softwareprodukten (in verschiedenen Ordnern vorhanden)?
Findet sich im Windowsverzeichniss unter System32
Danke für Deine Mühe. Möchte Dich bestimmt nicht verärgern.
Thomas,
wenn Du mich schon nicht verärgern willst, dann tue mir einen Gefallen
und beschreibe bitte nun final nachvollziehbar, wie Du das Problem
gelöst hast, insbesondere ob und was Du tun musstest um das
MsCOMM32-Symbol zur Anzeige zu bringen, damit Du es im zweiten Schritt
in eine "Form" einbinden konntest.
Zum Thema der Ansteuerung der seriellen Schnittstelle gibt es viele
Beiträge in diesem Forum.
Das mutmaßliche Alleinstellungsmerkmal der MSComm32.ocx ist, dass Du im
Gegensatz zu anderen Lösungen kein "busy waiting" in Deiner Anwendung
verursachen musst, um eingehenden Verkehr auf der Schnittstelle
abzufangen.
Harald K.,
danke für Deine Hinweise auf Freebasic!
Unter VBA in Excel 2000 unter WinXP SP3 habe ich eine fast
gleichlautende Syntax einmal ausprobiert.
Die dabei enstehende Verbindung war aber nicht stabil, wenn ich die
Daten eingelesen habe, per INPUT # oder GET#-Befehl.
Peter M. schrieb:> wenn Du mich schon nicht verärgern willst, dann tue mir einen Gefallen> und beschreibe bitte nun final nachvollziehbar, wie Du das Problem> gelöst hast, insbesondere ob und was Du tun musstest um das> MsCOMM32-Symbol zur Anzeige zu bringen, damit Du es im zweiten Schritt> in eine "Form" einbinden konntest.
Wenn Du mein Posting von 22:13 Uhr gelesen hättest, dann hättest Du
gewust, wie ich es bewerkstelligt hätte,
Hallo Thomas S.,
wir haben uns überschnitten, Deinen Beitrag habe ich deswegen nicht
gesehen - sonst hätte ich ja nicht jetzt noch mal nachfragen müssen.
Alles ist geklärt.
Thomas S. schrieb:> Kannst Du mir bitte erklären, was in den anderen Projekten dann 'schräg'> war, dass es nicht ging.
Keine Ahnung!
Das musst Du herausfinden.
Peter M. schrieb:> Unter VBA in Excel 2000 unter WinXP SP3 habe ich eine fast> gleichlautende Syntax einmal ausprobiert.> Die dabei enstehende Verbindung war aber nicht stabil, wenn ich die> Daten eingelesen habe, per INPUT # oder GET#-Befehl.
Ich hab' schon mal ein gelbes Buch gesehen, dessen Inhalt mir nicht
gefallen hat. Also vermeide ich konsequenterweise alle gelben Bücher,
denn das wird ja nicht von ungefähr gelb sein.
--
Du verquirlst hier Dinge, die überhaupt nichts miteinander zu tun haben.
Einerseits ist VBA nicht Visual Basic 6.0, andererseits ist FreeBasic
etwas komplett anderes, das vollkommen anders funktioniert.
Aus einer "Syntax" eines Systems darauf zu schließen, daß die eines
vollkommen anderen Systems "nicht stabil" sein könnte, ist so wie mein
Buchfarbenvergleich.
Warum man heutzutage noch XP nutzt, und warum man einen über 25 Jahre
alten Compiler nutzen will, kann ich mir nur mit Masochismus erklären.
Harald K. schrieb:> kann ich mir nur mit Masochismus erklären.
Lebenslauf-Optimierung:
Leute die das mit den aktuellen Hype-Programmiersprachen in 15 Minuten,
KI-unterstützt, fertigcoden gibt es wie Sand am Meer.
Jemand der sich da eine Woche Full-Time reinkniet, um es mit Ach und
Krach sowie Foren-Hilfe, auf einer prähistorischen Plattform gerade so
hinzukriegen ist ein Unikat.
I mean: Banken suchen verzweifelt Cobol-Programmierer, und zahlen denen
fette Gehälter. VisualBasic 6.0 ist genauso veraltet, müsste am
Arbeitsmarkt also genauso gefragt sein, oder?
Εrnst B. schrieb:> I mean: Banken suchen verzweifelt Cobol-Programmierer, und zahlen denen> fette Gehälter. VisualBasic 6.0 ist genauso veraltet, müsste am> Arbeitsmarkt also genauso gefragt sein, oder?
Hallo miteinander,
Dass VisualBasic 6.0 veraltet ist, mag sein. Mir würde es für das
bisschen immer noch reichen. Ich bin kein Profi-Proggi, aber ich baue
mir das, was ich gerade so brauche. Ich bin mal mit C unterwegs, mal mit
VBA unter Access und hier will ich was unter VB machen, da das Erstellen
der Formulare hier soweit entfällt, nur code hinterlegen.
Ich bin nicht drauf aus immer am Stand zu sein, Wenn es läuft, - never
touch a running System.
Und was schon mal gar nicht mag, sind die 365er Geschichten. Ein NoGo.
Ich habe hier so nebenbei noch Atari MegaST2 mit SCSI-HDD, 'Mehrere
Memotech MTX 512, Ein ZX81 (mit selbstgebauten 16KB, womit ich meine
Buchhaltung mache. - smile.
Εrnst B. schrieb:> Jemand der sich da eine Woche Full-Time reinkniet, um es mit Ach und> Krach sowie Foren-Hilfe, auf einer prähistorischen Plattform gerade so> hinzukriegen ist ein Unikat.
Ich bin dran gescheitert, dass VB dieses OCX nicht haben wollte, und
bislang nicht wusste an welcher 'versteckten' Schrauben man drehen muss,
um dieses Telefon und damit die Com-Funktionalität zu bekommen.
Habe in den 90er Jahren, wo das Internet so begann, Projekte unter Tools
gebaut, die heute keiner mehr kennt, und auch welche, die nur für unsere
Web-Firma damals konstruiert wurde. Es gab damals kein PHP, HTML5, CSS,
und Consorten.
Auch war ich lange Zeit dann unter Authorware Attain und
Datenbankanknüpfung (DataGrip) unterwegs.
So dumm bin ich nicht, nur liebe ich es mit der Umgebung zu arbeiten,
die ich kenne. Die Welt will ich nicht mehr neu erschaffen, nachdem was
heutzutage passiert, schaffen das nicht mal mehr die besten Gurus. Es
endet in absehbarer Zeit eh da, was uns Wall-E zeigte. Ich hoffe, dass
es die nächsten 50 Jahre noch so hält, wie gerad so ist. Aber 100 Jahre
wird fraglich, wenn alle nicht dran arbeiten, es zu erhalten. Das ist
der Punkt.
Dieses hier ist ein Forum, wo man sich unter Gleichgesinnten austauschen
kann, und sollte. Es ist keine Verkaufsplattform.
Nachtrag:
Was schafft Ihr denn bitte mit der KI??? - Nur Unbehagen.
Wollt Ihr euch in 5-10 Jahren von Maschinen kommandieren lassen?
Ich nicht - Die erste Maschine, die mir irgendetwas befiehlt, was mir
gegen den Strich geht, hat die Axt im Kreuz.
Grüße Thomas
Εrnst B. schrieb:> Leute die das mit den aktuellen Hype-Programmiersprachen in 15 Minuten,> KI-unterstützt, fertigcoden gibt es wie Sand am Meer.
Ich habe keine Hype-Programmiersprache als Alternative vorgeschlagen.
Sondern nur ein anderes Basic.
Thomas S. schrieb:> Es ist keine Verkaufsplattform.
Wofür könnte das "Free" in "FreeBasic" stehen?
Thomas S. schrieb:> Was schafft Ihr denn bitte mit der KI?
Was hat ein anderes Basic als VB mit "KI" zu tun?
Serielle Schnittstellen waren mit VB schon immer ein Krampf im Arsch,
einfach, weil man dafür so ein OCX benötigte, das man auch immer
irgendwie umständlich installieren musste - und, wie es sich zeigt, auch
nicht so ohne weiteres mit VB selbst verwendet werden kann.
Sich aus dieser Mühsal zu befreien und einfach ein anderes Basic zu
verwenden, das a) noch gepflegt wird, b) kostenfrei verfügbar ist und c)
sogar einem den Wechsel zu anderen Betriebssystemen ermöglicht (Linux),
sollte doch eigentlich befreiend sein.
Harald K. schrieb:> Sich aus dieser Mühsal zu befreien und einfach ein anderes Basic zu> verwenden, das a) noch gepflegt wird, b) kostenfrei verfügbar ist und c)> sogar einem den Wechsel zu anderen Betriebssystemen ermöglicht (Linux),> sollte doch eigentlich befreiend sein.
Das Argument könnte mich überzeugen. Sehe ich mir mal an.
Ich habe dieses eben da, und wollte ohne TramTram zum Ziel kommen. Nun
ist mir mit dieser Erklärung klar, dass VB evtl. nicht ganz der richtige
Weg wäre.
Aber nur um ein paar Bytes rüber zu schieben, dachte ich nicht an
Strömungserzeugung.
Harald K. schrieb:> Serielle Schnittstellen waren mit VB schon immer ein Krampf im Arsch,> einfach, weil man dafür so ein OCX benötigte
Das stimmt so schlicht nicht. Selbst mit diesen inzwischen völlig
veralteten Basic-Versionen war es durchaus möglich, das ganz normale
Win32-API dafür zu verwenden, ganz sicher jedenfalls war dies mit VB6
möglich, das habe ich damals(tm) nämlich selber getan. Das war zwar
nicht ganz einfach und ziemlich viel Schreibarbeit, aber durchaus
machbar.
Heute gibt es aber keinen Grund mehr, dies zu tun. Es gibt seit endlos
langer Zeit VB.net (was inzwischen nach MS' Willen wieder nur VB heißen
soll).
Damit ist das alles eigentlich ganz einfach. Aber klar: Es gibt Leute,
die kommen selbst damit nicht klar.
Ob S. schrieb:> Heute gibt es aber keinen Grund mehr, dies zu tun. Es gibt seit endlos> langer Zeit VB.net (was inzwischen nach MS' Willen wieder nur VB heißen> soll).
Nur ist VB.Net was völlig anderes als VB. Selbst die Profis haben damals
rebeliert und wollten bei VB6 bleiben.
Ich zähle mich bestimmt nicht zu den Profs. Und mein Geld verdiene ich
woanders. Aber mich interssiert es einfach, und habs halt da. Und für
das bisschen was ich produziere, reicht mir dies einfach. Punkt.
Mal bin ich auf C unterwegs, mal eben mit VBA, und hier unter VB.
Habe es oben geschrieben, war auch mit ganz firmenspezifischer Software
unterwegs und habe im Team größere Software-Projekte erstellt.
Jedem seins.
Thomas S. schrieb:> Nur ist VB.Net was völlig anderes als VB. Selbst die Profis haben damals> rebeliert und wollten bei VB6 bleiben.
Das ist jetzt aber über ein Vierteljahrhundert her.
Thomas S. schrieb:> Nur ist VB.Net was völlig anderes als VB.
Das ist wahr. Nämlich: eine gut durchdachte, moderne Sprache. Nunja,
anfangs gab es zur Unterstützung der Ewiggestrigen sogar noch einen
Haufen Kombatibilitätskram. Zumindest Teile davon verfolgen uns sogar
noch heute.
> Selbst die Profis haben damals> rebeliert und wollten bei VB6 bleiben.
Das waren keine Profis, sondern Vertreter der "das haben wir doch
immer schon so gemacht"-Fraktion. Die gibt es bei jeder Änderung von
egal was.
> Aber mich interssiert es einfach, und habs halt da.
Nunja, ein aktuelle VB ist auch nur einen kleinen kostenlosen Download
entfernt. Und hätte dir z.B. den ganze Ärger mit diesem unsäglichen OCX
erspart (welches es übrigens eigentlich nur gibt, weil die Realisierung
von Callbacks aus dem Win32-API unter VB6 nur so überaus kitzlig
umzusetzen war).
> Mal bin ich auf C unterwegs, mal eben mit VBA, und hier unter VB.
Und was spricht nun konkret gegen VB (in der modernen Inkarnation)? Da
hast du alles, was du auch in VB6 hattest. Nur besser und einfacher.
Aber halt an einigen Stellen auch etwas anders.
Ob S. schrieb:> Und was spricht nun konkret gegen VB (in der modernen Inkarnation)? Da> hast du alles, was du auch in VB6 hattest. Nur besser und einfacher.
Danke Dir für Deine Ausführung.
Ich werds mal überschlafen.
Der Hintergrund ist folgender: Ich habe eine Isel-CNC (116). Diese ist
bereits äußerst betagt. Das Programm zu dieser was mal dabei war ist
nicht mehr existent. Auch über Isel bekomme ich das nicht mehr.
Der andere Weg wäre, die Steuerkarte rauszuwerfen, und wie im anderen
Forumm drüben auf Mach3 oder LinuxCNC, oder ... umzustricken. Dazu habe
ich im Moment aber keine Lust.
Ich habe mir nun soweit bislang beholfen, dass ich die CNC mit einen
Terminal- Client (DockLight) angesteuert habe. Dazu habe ich ALLE
Kommandos per Scriptzeilen angelegt, und diese dann jeweils gestartet.
Klappte wunderbar soweit. Hat mir alles gefräst, was ich wollte, außer
natürlich 3D. Nur ... der Maschiene fehlt die Intelligenz. Wenn ich nun
falsche Parameter eingegen habe, ist diese halt dann über den zulässigen
Bereich gefahren. Passierte mir hin und wieder , weil ich vergessen
hatte den virtuellen Nullpunkt zuz setzen. Dann wusste die CNC halt
nicht wo sie ist. Merkte ich aber immer beim Starten.
Deshalb wollte ich nun eine einfache Oberfläche bauen, wo ich die
Maschine steuern kann, und andererseits das Programm Fehler abfängt, um
die CNC nicht zu zerstören.
Dann der nächste Schritt würde sein, Zeichnungen per Corel Draw zu
erstellen, und per DXF-Export an mein Programm weiterreichen.
Es gibt fertige Sachen, klar. Aber wir sind hier in einem Forum, wo
gebastelt wird, und dann ist das doch eine schöne Sache.
Dass ich niemals an LinuxCNC rankomme klar, will ich auch nicht.
Thomas S. schrieb:> Deshalb wollte ich nun eine einfache Oberfläche bauen, wo ich die> Maschine steuern kann, und andererseits das Programm Fehler abfängt, um> die CNC nicht zu zerstören.
Dagegen spricht ja nichts. Nur muss man das nicht mit VB6 machen, da
gibt es doch viele andere Möglichkeiten.
Und wenn's Geld kosten darf, gibt es auch weitere Basic-Varianten:
PureBasic https://www.purebasic.com/german/
xojo (ehemals RealBasic) https://www.xojo.com/
(Es gab auch mal PowerBasic, das aber wurde Anfang des Jahres vom
Hersteller getötet
https://web.archive.org/web/20231221060419/http://www.powerbasic.com/)
Suche dir doch eine Sprache, die das (COM-Schnittstelle) von Haus aus
kann und wo keine Verweise oder Abhängigkeiten für ein Modul bzw.
Library oder sonst was benötigt werden.
Wie Harald schon erwähnt hat, reicht da auch PureBasic oder auch mein
Favorit XProfan (www.Profan.de) für kleine Sachen. Profan 10 als ältere
Version gibt es auch kostenlos. Da braucht es auch keine große
Installation.
Und für ein paar Buttons und ein Editfeld braucht es auch nicht
unbedingt
einen Visual-Designer.
Bis du bei den großen Bolliden ersten Erfolg mit der Einbindung der COM
verbuchen kannst, hast du dich anderswo auch schon etwas eingearbeitet.
Hallo Heinz B.,
Heinz B. schrieb:> Suche dir doch eine Sprache, die das (COM-Schnittstelle) von Haus aus> kann und wo keine Verweise oder Abhängigkeiten für ein Modul bzw.> Library oder sonst was benötigt werden.
Der Zugriff auf die COM-Schnittstelle funktioniert schon in Excel 2000
auch ohne externe Module.
Peter M. schrieb:> Hallo Heinz B.,>> Heinz B. schrieb:>> Suche dir doch eine Sprache, die das (COM-Schnittstelle) von Haus aus>> kann und wo keine Verweise oder Abhängigkeiten für ein Modul bzw.>> Library oder sonst was benötigt werden.>> Der Zugriff auf die COM-Schnittstelle funktioniert schon in Excel 2000> auch ohne externe Module.
Im Prinzip: ja.
Aber asynchron aber nur mit recht erheblichen Anforderungen an die
Qualität des Programierers. Das Problem ist es, die Callbacks des
asynchronen Win32-API wieder "sauber" in die VB (oder auch: VBA-)
Umgebung zu bekommen. Das ist leider alles andere als trivial.
Weil das halt so kompliziert ist und eine serielle Schnittstalle sich
eigentlich nur im asynchronen Betrieb wirklich sinnvoll verwenden läßt,
hat MS halt lieber dieses MSCOMM.OCX geschaffen, was den ganzen
Sackstand außerhalb der VB/VBA-Umgebung abhandelt.
Ob S. schrieb:> Aber asynchron aber nur mit recht erheblichen Anforderungen an die> Qualität des Programierers. Das Problem ist es, die Callbacks des> asynchronen Win32-API wieder "sauber" in die VB (oder auch: VBA-)> Umgebung zu bekommen. Das ist leider alles andere als trivial.
Welche Callbacks?
Aus VBA ruft man die API-Funktionen auf. Bitte erkläre mir, wo Callbacks
auftreten, das verstehe ich nicht.
Problematisch wird das erst, wenn die Schnittstelle gepollt werden
muß, um keine Daten zu verlieren. Da kommt man um einen Thread meist
nicht herum. Wenn er aber nur ein paar Konfigurationsdaten schicken
bzw. empfangen will und die CNC antwortet entsprechend, sehe ich da
kein Problem. Er hat ja schon geschrieben, daß er ein paar Buttons
erstellen will, um mit diesen halt die Kommandos entsprechend senden
will. Das geht auch mit einem kleinen BASIC, das Befehle zum Öffnen,
Konfigurieren, Schreiben, Lesen und Schließen der Schnittstelle
beherrscht.
Nötigenfalls muß man nach dem Senden 200 - 300 ms warten und dann erst
den Empfangspuffer auslesen. Das kommt dann auf die CNC selber an.
Durch Ausprobieren kommt man da auch an eine gewisse ASynchronität
heran.
Sowas ähnliches hatte ich auch schon mit XProfan und einer 4-fach
Relaiskarte vom großen C erfolgreich gemacht.
Manche ziehen halt gerne den großen Werkstattwagen heraus, auch wenn
im Vorraus bekannt ist, daß nur ein 10er Ring und einer 10er
Maulschlüssel
gebraucht wird.
Hallo Heinz B.,
Heinz B. schrieb:> Nötigenfalls muß man nach dem Senden 200 - 300 ms warten und dann erst> den Empfangspuffer auslesen. Das kommt dann auf die CNC selber an.> Durch Ausprobieren kommt man da auch an eine gewisse ASynchronität> heran.
genauso ist es!
Wenn es keine Hochfrequenzdaten sind, erzeugt die zyklisch Abfrage der
Schnittstelle bzw. des Puffers auch kein "busy waiting" mit 100%
Prozessorlast.
Peter M. schrieb:> Aus VBA ruft man die API-Funktionen auf. Bitte erkläre mir, wo Callbacks> auftreten, das verstehe ich nicht.
OMG.
Zentral für das asynchrones File-API allgemein:
BOOL ReadFile(
[in] HANDLE hFile,
[out] LPVOID lpBuffer,
[in] DWORD nNumberOfBytesToRead,
[out, optional] LPDWORD lpNumberOfBytesRead,
[in, out, optional] LPOVERLAPPED lpOverlapped
);
Man beachte hier den Verweis auf eine OVERLAPPED-Struktur. Da steht der
Rest drinne, der für asynchrone Filezugriffe erforderlich ist. U.a. halt
auch die Adresse des Callbacks, den das OS aufruft, wenn die
angeforderte Aktion abgeschlossen oder (asynchron) gescheitert ist.
Bezüglich der seriallen Schnittstellen kommt dazu aber noch was, was
sich mit den diversen sonstigen Signalen der Schnittstelle asynchron
auseinander setzt, die nicht direkt zum Filetransfer gehören:
BOOL WaitCommEvent(
[in] HANDLE hFile,
[out] LPDWORD lpEvtMask,
[in] LPOVERLAPPED lpOverlapped
);
Auch hier wieder der Verweis auf die Overlapped-Struktur, die dann die
Adresse des Callbacks enthält.
Peter M. schrieb:> Wenn es keine Hochfrequenzdaten sind, erzeugt die zyklisch Abfrage der> Schnittstelle bzw. des Puffers auch kein "busy waiting" mit 100%> Prozessorlast.
Wenn man es zyklisch haben will : Fast jede BASIC Sprache kennt auch
einen Windows-Timer. Ab 300 ms aufwärts habe ich da gute Erfahrungen
gemacht. Da friert auch die GUI so schnell nicht ein.
Peter M. schrieb:> Wenn es keine Hochfrequenzdaten sind, erzeugt die zyklisch Abfrage der> Schnittstelle bzw. des Puffers auch kein "busy waiting" mit 100%> Prozessorlast.
Dieses Stoppelhops-Polling ist das Mittel der Armen. Klar, es hält
wenigstens die Anwendung benutzbar, erzeugt aber nach wie vor *völlig
unnütze* CPU-Last. Bloß halt weniger.
Also es freut mich, dass die Community hier doch mit eifrig dran ist.
Sag ich erst mal danke und klasse.
Die Isel CNC ist, wie ich bemerke nicht wirklich schnell im
komzunizieren. Also auch kein Problem mit irgendwelchen Timings. Wenn
ich einen Out-Port ansteuere, dauert das fast ne Sekunde, bis der Port
sein Bitbimsel in der Isel ändert.
Bin da grad dabei das Input, wie Output zur Isel zu verstehen.
Was in VB z.B. nicht geht ist Bitmanipulation. Wenn ich im Port 1 bit 2
eine/aus schalten will, ohne die anderen zu verändern. Habe da aber was
gefunden, da bin ich grad dran. Oder ich geh her, und addiere in
Abhängigkeit, ob Checked oder nicht einfach 1, 2, 4, 8, 16, 32, 64 und
128. Die Summe übertrage ich dann zur Isel. Damit ist der Port
entsprechend gesetzt.
Wollte auch mal ein Lebenszeichen von mir hier zeigen.
Thomas S. schrieb:> Was in VB z.B. nicht geht ist Bitmanipulation.
Wen willst du hier verarschen? VB kennt dieselben Möglichkeiten zur
Bitmanipulation wie jede andere ernstzunehmende Programmiersprache auch.
Im Gengensatz zu solchen Klartext-Verschlüsselungs-Sprachen wie etwa
C/C++ muß man die Operatoren dazu nicht mal erst aus irgendwelchen
Sprach-Dokus extrahieren. Nö, man kann sie einfach im (englischen)
Klartext hinschreiben.
Das galt für die ollen VB-Inkarnationen und gilt auch noch für die
aktuellen.
Eines muß man sich immer vor Augen halten :
Windows ist bis heute nicht multitasking - fähig. Es vergibt daher
solche Zeitscheiben. Bloß unser träges, menschlische Auge erfaßt
das nicht. Und die neueren Prozessoren tragen da auch etwas bei.
Thomas S. schrieb:> Die Isel CNC ist, wie ich bemerke nicht wirklich schnell im> komzunizieren. Also auch kein Problem mit irgendwelchen Timings. Wenn> ich einen Out-Port ansteuere, dauert das fast ne Sekunde, bis der Port> sein Bitbimsel in der Isel ändert.>> Bin da grad dabei das Input, wie Output zur Isel zu verstehen.
Die soll ja auch was anderes tun, als dir nur zuzuhören. Entweder
springt die zyklisch, wenn sie eine Teilaufgabe fertig hat, in eine
Lauscherstellung oder wird evtl. auch von einem Interrupt
benachrichtigt.
Außerdem muß das ja auch durch ein Kabel und 2 Ports. Da ist die
Treiberschicht von der COM noch nicht berücksichtigt. Also nach dem
Motto : wenns klingelt, machst du auch nicht innerhalb einer Sekunde
die Tür auf.
Aber um das mit den Interrupts zu verstehen, sollte man aus der guten
alten MS-DOS - Zeit Erfahrung haben. Da wurde in ASM ein Buchtsabe in
ein bestimmtes Register kopiert und ein INT 21 H (Bildschirm-Interrupt)
erzeugt, der den Buchtstaben in den Bildschirmspeicher schrieb.
Heinz B. schrieb:> Windows ist bis heute nicht multitasking - fähig.
Wie kommst Du auf diese bizarre Idee? Und ob es das ist. Präemptiv seit
1993, kooperativ auch in den 16-Bit-Versionen seit Urschleim.
Was für eine Definition von "Multitasking" siehst Du nicht erfüllt?
Heinz B. schrieb:> Aber um das mit den Interrupts zu verstehen
... hilft Dein Beispiel nicht, weil ein Softwareinterrupt nur der Aufruf
einer BIOS- (oder Betriebssystem-) Funktion ist, aber nichts mit einem
von Hardware (wie einer UART) ausgelösten Interrupt zu tun hat.
Heinz B. schrieb:> Eines muß man sich immer vor Augen halten :> Windows ist bis heute nicht multitasking - fähig. Es vergibt daher> solche Zeitscheiben.
So ein Bullshit. Jeder normale Mensch hält gerade das Konzept der
Vergabe von Zeitscheiben für den primären Angelpunkt einer (präemptiven)
Multitasking-Struktur. Macht nicht nur Windows so, sondern ausnahmslos
ALLE heute noch üblichen OS.
> Bloß unser träges, menschlische Auge erfaßt> das nicht. Und die neueren Prozessoren tragen da auch etwas bei.
Ja, vor allem dadurch, dass sie über mehrere Kerne verfügen, deren
Anwesenheit überhaupt erst mal die Grundvoraussetzung dafür ist,
irgendwas tatsächlich parallel zu bearbeiten. Und mit mehreren Kernen
kann Windows seit bald drei Jahrzehnten umgehen...
> Interrupts
Auch mit Interrupts kann man mit nur einem einzelnen Kern nichts
wirklich parallel bearbeiten. Solange die IRQ-Routine ausgeführt wird,
ruht der Code in main() und macht garnix.
Hallo Ob S.,
Ob S. schrieb:> Auch hier wieder der Verweis auf die Overlapped-Struktur, die dann die> Adresse des Callbacks enthält.
das ändert nichts daran, dass mein VBA-Code keine Callbacks enthält,
sagt Dir ein "armer Stoppelhops-Poller"! :)
Callback heißt, dass dem Betriebssystem eine VBA-Routine übergeben wird
und das Betriebssystem die VBA-Routine aufruft.
Callbacks gibt es offensichtlich nur innerhalb des Betriebssystems, ich
muss auf keine Aufrufe von VBA-Funktionen oder -prozeduren durch das
Betriebssystem antworten.
Ob S. schrieb:> Dieses Stoppelhops-Polling ist das Mittel der Armen. Klar, es hält> wenigstens die Anwendung benutzbar, erzeugt aber nach wie vor *völlig> unnütze* CPU-Last. Bloß halt weniger.
Bei mir wird alle 2 Sekunden ein Wert abgefragt. Dafür gibt es eine
Timer-Funktion, busy waiting ist nicht erforderlich. Leider hat der
VBA-Timer anscheinend nur Sekundenauflösung.
Dannach heißt es >=80 ms Warten auf das Ergebnis.
Das realisiere ich mit busy waiting in einer Schleife, die aber nach
jeder Abfrage des Tick-Timers die Kontrolle an das Betriebssystem
zurückgibt.
Ja, das erzeugt Zusatzlast, die ich noch nicht gemessen habe, weil ich
keine Bremswirkung gespürt habe.
Technisch ist die Umsetzung wie MSComm32-OCX sicherlich die solideste
Lösung.
Mein Code läuft aber immer, egal ob das MSComm32-OCX installiert ist
oder nicht. Ich brauche keinen Installer dafür zu schreiben, und muss
auch nicht aus dem Code heraus abfragen, ob das OCX erfolgreich
installiert wurde oder ist und auch keine Verweise mehr in VBA setzen.
Ich brauche auch keine Admin-Rechte zur Installation des OCX. Ich
brauche kein VB6 zu kaufen oder ominöse Netz-Downloads mit
Seriennummerfunden in meinem System zu integrieren.
Wie immer stellt sich die Frage nach dem besten Werkzeug für ein
Problem. Und wenn ich nicht zufrieden bin, dann werde ich sicherlich die
dicke Berta in Form von MSComm32 zum Einsatz bringen! :)
Thomas S. schrieb:> Was in VB z.B. nicht geht ist Bitmanipulation. Wenn ich im Port 1 bit 2> eine/aus schalten will, ohne die anderen zu verändern. Habe da aber was> gefunden, da bin ich grad dran. Oder ich geh her, und addiere in> Abhängigkeit, ob Checked oder nicht einfach 1, 2, 4, 8, 16, 32, 64 und> 128. Die Summe übertrage ich dann zur Isel. Damit ist der Port> entsprechend gesetzt.
Schau' Dir mal im Visual-Basic-Sprachverzeichnis die Operatoren an: AND,
OR, XOR, NOT. Damit kommst Du einfacher zum Ziel!
Heinz B. schrieb:> Eines muß man sich immer vor Augen halten :> Windows ist bis heute nicht multitasking - fähig. Es vergibt daher> solche Zeitscheiben. Bloß unser träges, menschlische Auge erfaßt> das nicht. Und die neueren Prozessoren tragen da auch etwas bei.
Multitasking auf einem Prozessor erfordert immer Zeitscheibenbetrieb,
wenn nicht durch andere Methoden wie Hyperthreading Parallelbetrieb
möglich gemacht wird. Der Task Manager zeigt dir ganz viele parallel
laufende Tasks unter Windows, auch auf einem Ein-Prozessor-System.
Die spannende Frage in der heutigen Hardware-Welt lautet nur noch, ob
eine rechenintensive Anwendung Multitasking unterstützt.
Ob S. schrieb:> Thomas S. schrieb:>>> Was in VB z.B. nicht geht ist Bitmanipulation.>> Wen willst du hier verarschen? VB kennt dieselben Möglichkeiten zur> Bitmanipulation wie jede andere ernstzunehmende Programmiersprache auch.
Nein ich möchte hier niemanden verarschen.
Habe ich so in einen VB Forum gefunden.
Link:https://www.vbarchiv.net/tipps/tipp_1276-abfragen-setzen-und-loeschen-von-bits.html
VB verfügt über bitweise arbeitende Operatoren (AND, EQV, IMP, OR). In
Kombination mit dem NOT-Operator lassen sich die Bitmuster von zwei
Variablen auf alle denkbaren Arten kombinieren. (Der XOR-Operator
entspricht der Negation der EQV-Verknüpfung.)
Was es in VB aber nicht gibt, sind Funktionen, durch die man direkt
einzelne Bits in einer Variable abfragen, setzen oder löschen kann.
Zum letzten Absatz. Genau das wollte ich erreichen. und dann hier diese
Erklärung.
Ich habe dies nun folgendermaßen gelöst. Es ist hier nur Port 1 - Bit1
und Port 2 - Bit 2 und die ausführende Routine gezeigt.
Aufruf:
1
Private Sub Check1_Click()
2
3
bitpos = 1
4
5
If Check1.Value = vbChecked Then
6
Port_A_Array(1) = 1
7
Else
8
Port_A_Array(1) = 0
9
End If
10
Port_1_Bitsettings
11
End Sub
12
13
Private Sub Check10_Click()
14
If Check10.Value = vbChecked Then
15
Port_B_Array(2) = 1
16
Else
17
Port_B_Array(2) = 0
18
End If
19
Port_2_Bitsettings
20
21
End Sub
Die Portsteuer-routine:
1
Private Sub Port_1_Bitsettings()
2
3
Portbits = 0
4
If (Port_A_Array(1) = 1) Then Portbits = Portbits + 1
5
If (Port_A_Array(2) = 1) Then Portbits = Portbits + 2
6
If (Port_A_Array(3) = 1) Then Portbits = Portbits + 4
7
If (Port_A_Array(4) = 1) Then Portbits = Portbits + 8
8
If (Port_A_Array(5) = 1) Then Portbits = Portbits + 16
9
If (Port_A_Array(6) = 1) Then Portbits = Portbits + 32
10
If (Port_A_Array(7) = 1) Then Portbits = Portbits + 64
11
If (Port_A_Array(8) = 1) Then Portbits = Portbits + 128
12
13
MSComm1.PortOpen = True
14
szString = "@0B65529," & Portbits
15
MSComm1.Output = szString & Chr(13)
16
17
MSComm1.PortOpen = False
18
19
End Sub
20
'****************************************
21
Private Sub Port_2_Bitsettings()
22
23
Portbits = 0
24
If (Port_B_Array(1) = 1) Then Portbits = Portbits + 1
25
If (Port_B_Array(2) = 1) Then Portbits = Portbits + 2
26
.....
Weiß nicht, ob man das 'eleganter' lösen kann? - So funktioniert es.
Thomas S. schrieb:> Weiß nicht, ob man das 'eleganter' lösen kann? - So funktioniert es.
Wenn Du viele Ports hast, dann kannst Du den Code massiv eindampfen. Die
ganzen Abfragen Deines Port-Arrays (die Du auch durch eine Schleife
hättest ersetzen können) um das Portstatus-Byte zu konfigurieren,
entfallen.
Speichere den Portstatus pro Port in einem Byte:
Global:
Dim portA as byte
Dim portB as byte
Private Sub Check10_Click()
If Check10.Value = vbChecked Then
portA=bitSet(portA,2)
Else
portB=bitClear(portA,2)
End If
portupdate(@0B65529,portA)
End Sub
Public function bitSet(portStatus as byte, bit as byte) as byte
bitset= portStatus or 2^bit
end sub
Public function bitCleaer(portStatus as byte, bit as byte) as byte
bitClear= portStatus and not(2^bit)
end sub
public sub PortUpdate(PortID as string, portStatus as byte)
Dim szString
MSComm1.PortOpen = True
szString = PortID & "," & portStatus
MSComm1.Output = szString & Chr(13)
MSComm1.PortOpen = False
end sub
Peter M. schrieb:> Callback heißt, dass dem Betriebssystem eine VBA-Routine übergeben wird> und das Betriebssystem die VBA-Routine aufruft.
Genau. Und das ist halt alles andere als einfach einfach, weil VB(A) ein
Interpreter ist, der einen Kontext benötigt.
Es enthält allerdings die nötigen Mechanismen, um Callbacks aus dem OS
auszuführen, diese sind allerdings nicht dokumentiert.
Bei VB (in der modernen Inkarnation als VB.net) hingegen sind sie es.
> Callbacks gibt es offensichtlich nur innerhalb des Betriebssystems
Das ist natürlich völliger Unsinn. Sagt schon die reine Logik: wieso
sollte ein OS einer Anwendung ein API verfügbar machen, welches sie
nicht nutzen kann?
Also bitte: Wenigstens ein wenig Nachdenken vor dem Posten kann wirklich
nicht schaden...
Hallo Ob S.,
Ob S. schrieb:> Peter M. schrieb:>>> Callback heißt, dass dem Betriebssystem eine VBA-Routine übergeben wird>> und das Betriebssystem die VBA-Routine aufruft.>> Genau. Und das ist halt alles andere als einfach einfach, weil VB(A) ein> Interpreter ist, der einen Kontext benötigt.>> Es enthält allerdings die nötigen Mechanismen, um Callbacks aus dem OS> auszuführen, diese sind allerdings nicht dokumentiert.
Das ist mir neu, danke!
>> Bei VB (in der modernen Inkarnation als VB.net) hingegen sind sie es.>>> Callbacks gibt es offensichtlich nur innerhalb des Betriebssystems>> Das ist natürlich völliger Unsinn. Sagt schon die reine Logik: wieso> sollte ein OS einer Anwendung ein API verfügbar machen, welches sie> nicht nutzen kann?
Das war unpräzise von mir formuliert. In meinem VBA-Code gibt es Aufrufe
à la Open, Close, Read und Write aber keinen Callback des
Betriebssystems.
Ein Callback würde aber sinnvoll bei einem Read-Aufruf sein. Der
Read-Aufruf sollte ja nicht bis zum jüngsten Gericht warten, sondern am
besten ergebnislos zurückkehren. Die Aufgabe des Callbacks bestünde dann
darin, mitzuteilen, das im Puffer etwas liegt.
> Also bitte: Wenigstens ein wenig Nachdenken vor dem Posten kann wirklich> nicht schaden...
Da hast Du Recht!
Thread beobachten
Seitenaufteilung abschalten