Codeumwandlung oder umstieg nach VB?

[Metaller]

Leider das gleiche Ergebnis *heul*. Laut MSDN, die ich mir gestern mit C++.net daraufgespielt habe, sagt, dass wenn dwError und GetLastError gleich Null sind, dann ist ein Timeout aufgetreten. Also reagiert die Anwendung nicht auf meinen Request

Daraufhin habe ich alle Funktionen nochmals überprüft und bin zu dem Ergebnis gekommen, dass alles eigentlich Ok sein müßte. Selbst GlobalGetAtomName hat mit die richtige Länge des Strings und den Namen ausgegeben, den ich vorher registriert gabe.
FindWindowEx ist auch in Ordnung, denn wenn ich das andere Programm schließe, wird ein Fehler angezeigt. Also stimmt auch "UIPCMAIN".

Ich denke, dass es ein hoffnungsloses Vorhaben ist, die Quellcodes nach PB zu übersetzen. Vielen, vielen Dank für Eure Mithilfe.

[Metaller]

Falls es jemanden noch interessiert und evtl. auch mal in die Situation kommen sollte, kommen hier noch ein paar Anmerkungen. Da ich jetzt einfach nur rumsitze und auf die DLL warte, habe ich mir nochmals meinen Code und die WinAPI bzw. die MSDN Zur Hand genommen. Und habe folgenden Befehl gefunden:

Code: Alles auswählen

GetMessage_(@msg,hwnd,wParam,lParam)

Auf diesen Befehl hin bekomme ich eine Rückmeldung von meiner msg, in Form einer 1. Was bedeutet, dass alles soweit korrekt initialisiert wurde. Ich kann mir das nur damit erklären, das meine msg im Bereich unter $7FFF liegt und somit als Privat deklariert wird und "SetWindowCallback" evtl. nur auf msg's reagiert die entweder über $7FFF liegen oder ausschließlich auf Windows reagieren.

Leider das gleiche Ergebnis *heul*. Laut MSDN, die ich mir gestern mit C++.net daraufgespielt habe, sagt, dass wenn dwError und GetLastError gleich Null sind, dann ist ein Timeout aufgetreten. Also reagiert die Anwendung nicht auf meinen Request

Den Fehler habe ich behoben. Ich hatte vergessen folgendes zuschreiben:

Code: Alles auswählen

CreateFileMapping_($FFFFFFFF, 0, 4, #Null, $7FFF, @szName)

Danach funktionierte auch die SendMessageTimeout-Funktion. "@dwError" meldete mir eine '1' und GetLastError eine '0' zurück, was lt. MSDN richtig sein sollte. Hier der Ausschnitt aus der MSDN über die SendMessageTimeout-Funktion:

Return Value

If the function succeeds, the return value is nonzero.

If the function fails or times out, the return value is zero. To get extended error information, call GetLastError. If GetLastError returns zero, then the function timed out. SendMessageTimeout does not provide information about individual windows timing out if HWND_BROADCAST is used.

Ich hoffe ich habe den Abschnitt richtig verstanden

[mk-soft]

Interressant mit "RegisterWindowMessage"
Funktioniert

Code: Alles auswählen

  #MSGNAME1 = "FSASMLIB:IPC"
  Global m_msg = RegisterWindowMessage_(#MSGNAME1)
 
 
  Procedure WndProc(hwnd,uMsg,wParam,lParam)
   
    ; message abfangen
    If uMsg = #WM_MOVE
      Debug "fenster wird bewegt"
    EndIf
   
    ; deine message
    If uMsg = m_msg
      Debug "FSASMLIB:IPC"
      ProcedureReturn 1234567890 ; <-- result
    EndIf
   
    ; in etwa das gleiche wie CallWindowProc_()
    ProcedureReturn #PB_ProcessPureBasicEvents
  EndProcedure
 
  #fenster = 0
  hwnd = OpenWindow(#fenster,#PB_Ignore,#PB_Ignore,300,300,"Test")
 
  SetWindowCallback(@WndProc(),#fenster) ; mit @ bekommt man die adresse
                                         ; der Procedure , variable usw...
  hwnd = FindWindow_(0,"Test")
 
  Debug SendMessage_(hwnd,m_msg,0,0)
 
  Repeat
    event = WaitWindowEvent()
   
  Until event = #WM_CLOSE

Habe mal getestet. Beim zweiten aufruf (Test läuft) bekommt man die gleiche Message-Nummer geliefert und aus den ersten "Test" bekommt man das richtige result.

[Metaller]

Ich habe mich gefragt, warum in den VB und REALBasic Programmen immer fogendes stand:

Code: Alles auswählen

Declare Function RegisterWindowMessage& Lib "user32" Alias _"RegisterWindowMessageA" (ByVal lpString As String)

Also dachte ich mir mache ich das auch mal:

Code: Alles auswählen

OpenLibrary(0, "user32.dll")
m_msg = CallCFunction(0, "RegisterWindowMessageA", "FSASMLIB:IPC")
CloseLibrary(0)

Leider auch ohne Erfolg

Danach habe ich mich mal mit den Aufrufen mit und ohne 'A' und 'W' auseinandergesetz und mich gefragt, warum wird diese Art der Deklarierung bei den verschiedenen Basic Varianten gemacht aber nicht bei den C/C++ Arten. Heraus kam, das man in den Conpiler Optionen die Text-Kodierung des Quellcodes auf "UTF-8" stellen muß. Erst danach lief mein, in diesem Beitrag abgebildeter Code, fehlerfei, auch ohne die OpenLibrary Funktion

Das kann es doch nicht sein

Naja, wenn es so weiter geht, dann brauche ich auch die DLL nicht mehr. Schon komisch das Ganze

[ts-soft]

Fast alle API Funktionen sind in PB bereits definiert. Das A oder W am ende
einiger Funktionen deutet auf eine ANSI und Unicode Version hin, diese
Unterscheidung ist im allgm. in PureBasic überflüssig, der Compiler nutzt die
passende Version anhand der Compilereinstellungen, also W bei Unicode Exe
und A bei ANSI (ASCII) Version. UTF-8 solltest Du als Default in der IDE
einstellen, dann funktioniert es immer, unabhängig der Compilereinstellung.

Die plain Text (reiner Text) Einstellung ist eigentlich nur noch zur
Kompatiblität mit älteren Sourcen nützlich.

Gruß
Thomas

[Metaller]

UTF-8 solltest Du als Default in der IDE einstellen, dann funktioniert es immer, unabhängig der Compilereinstellung.

Schön zu wissen In der Anleitung steht auch sowas, aber ich konnte bisher nichts damit anfangen. Evtl. sollte die Einstellung schon bei der Installation "richtig" gesetzt werden, um den Noobs die Arbeit einwenig leichter zu machen. Wie dem auch sei, aus Fehlern lernt man!