Check if Application is Running Without Timer

The original entry point is defined as /ENTRY:__vbaS where __vbaS is a routine that initializes the runtime libraries.

Quote:

---

The above code works fine when run under a VB App... thats all we wanted.

---

Well we want more. We want the dll to be able to run in a process that is seperate from the VB program.

The dll will attach itself to all running windows that receive any WH_SHELL messages. Most of these will not be VB programs.

OK, LOL,

Even i am confused now..

Quote:

---

The original entry point is defined as /ENTRY:__vbaS where __vbaS is a routine that initializes the runtime libraries

---

The above point is right... But what if a predefined routine Microsoft made in the name of "DLLMain" hehe.. sounds kinky :p

I will be back with more TESTs. Also i am not sure how i could call in VC++ I have almost no knowledge of VC++ ... so i just need a code from moeur or someone to call an API... that might give solution to our questions

VB Code:

Public hInstance As Long ' One of the useful infos we get from DllEntry point
 
Public ret As Long
 
Public Const DLL_PROCESS_DETACH = 0
Public Const DLL_PROCESS_ATTACH = 1
Public Const DLL_THREAD_ATTACH = 2
Public Const DLL_THREAD_DETACH = 3
 
Public Function DLLMain(ByVal hInst As Long, ByVal fdwReason As Long, lpvReserved As Long) As Long
   Select Case fdwReason
      Case DLL_PROCESS_DETACH
         ' No per-process cleanup needed
      Case DLL_PROCESS_ATTACH
         ' No per-process initialization needed
         'MessageBox 0, "Hi from DLL " & hInst, "Hi", 1
         'MsgBox "This is a VB Function", vbCritical
         
         Call Some_VB_Tests()
         
      Case DLL_THREAD_ATTACH
         ' No per-thread initialization needed
      Case DLL_THREAD_DETACH
         ' No per-thread cleanup needed
   End Select
 
   hInstance = hInst  ' This is the App.Instance Parameter
   DLLMain = 1        ' Return 1 on success
End Function
 
Public Function GetRetValue() As Long
    GetRetValue = ret
End Function
 
Private Function Some_VB_Tests()
On Error GoTo ErrH
    ' returns how many test VB has passed
 
    ''' Test 1
    
    ' Exit Function
    
    Do
        ret = ret + 1
    Loop While MsgBox("MsgBox Test Passed", vbRetryCancel) = vbRetry
    
    ''' Test 2
 
    Do
        ret = ret + 1
        Call Shell("notepad", vbMaximizedFocus)
    Loop While MsgBox("Shell Test", vbRetryCancel) = vbRetry
 
    Do
        ret = ret + 1
        Call AppActivate("Untitled - Notepad", True)
    Loop While MsgBox("AppActivate", vbRetryCancel) = vbRetry
 
    Do
        ret = ret + 1
        Call AppActivate("Untitled - Notepad", True)
        Call SendKeys("SENDKEYS PASSED~~~ REMEMBER SENDKEYS IS A NATIVE VB FUNCTION", True)
    Loop While MsgBox("AppActivate + SendKeys", vbRetryCancel) = vbRetry
 
Dim arr() As String, i As Integer
    Do
        ret = ret + 1
        ReDim Preserve arr(i) As String
        arr(i) = "Val" & i
        i = i + 1
    Loop While MsgBox("Runtime Array assignment Test! Arr Count: " & UBound(arr), vbRetryCancel) = vbRetry
 
Dim Source As String
 
Source = "This is a test string where all spaces will be removed one by one"
    Do
        ret = ret + 1
        Source = Replace$(Source, " ", "", , 1)
    Loop While MsgBox("Replaced String: " & Source, vbRetryCancel) = vbRetry
 
 
Exit Function
ErrH:
    MsgBox Err.Number & vbCrLf & Err.Description
    Err.Clear
End Function

So now the result is: All Tests have passed.


But whenever an error occurs, the library unloads

So i have used even error handling in the test.. it worked too.. It was able to show what the error number and description were..

{EDITED}: Included Replace test

It's probably better to no run too much code out of the dllMain since all the initialization could not be complete.

I'll try to implement the changes you've made to the linker, test it on a simple program, then see if it works when I try to hook Notepad or something.

CodeBlock
Can you post the code for your link.exe
After adding the changes mine is not working

Nevermind:

Found the bug in my code "DLLMain" <> "DllMain"
Now time to test with an out of process hook application.

No Joy :(

Quote:

---

Originally Posted by moeur

CodeBlock
Can you post the code for your link.exe

---

Sorry, for the delay, we got to adjust with our Global Zone Timings

And before that.. please gimme a source in VC++ for me to test my VB DLL ... As in an equivalent code in VC++ for this:

VB Code:

Private Declare Function SampleFunction Lib "MyVBW32DLL.dll" () As Long
 
Private Sub Form_Load ()
Dim retVal As Long
   retVal = SampleFunction()
End Sub

OK, This is the Linker source:

VB Code:

Option Explicit
 
Private Const LINK_FILE = "LINKER.EXE"
 
Dim FSO As FileSystemObject
 
Private Sub cmdCancel_Click()
 
Open App.Path & "\LinkerLog.txt" For Append As #1
 
    Print #1, Now & ": ============================================"
    Print #1, Now & ": Command Line Options:   "; Command$
    Print #1, Now & ": ============================================"
    Print #1, vbCrLf & vbCrLf
    
Close #1
 
ShellWait App.Path & "\" & LINK_FILE & ".exe " & Command$
    Unload Me
End Sub
 
Private Sub CmdOk_Click()
 
    Dim CmdLine As String
    CmdLine = Command$
    
    CmdLine = Replace(CmdLine, "/ENTRY:__vbaS", "/ENTRY:DLLMain") ' BookMark #1
    CmdLine = Replace(CmdLine, "/BASE:0x400000", "/BASE:0x10000000")
    CmdLine = CmdLine & " /DLL /DEF:" & """" & txtCompiler.Text & """"
 
    If Len(Dir(txtCompiler.Text, vbNormal)) <= 0 Then
        MsgBox "No such DEF file.. please verify again!"
        Exit Sub
    End If
 
    LINK CmdLine
    
End Sub
 
Private Sub Form_Load()
    
    Dim intPos As Integer
    Dim strPath As String
    
    Dim fld As Folder
    Dim fil As File
    
    Set FSO = New FileSystemObject
     
     
        ' Determine if .DEF file exists
    '
    ' Extract path from first .obj argument
    intPos = InStr(1, Command$, ".OBJ", vbTextCompare)
    strPath = Mid$(Command$, 2, intPos + 2)
    intPos = InStrRev(strPath, "\")
    strPath = Trim$(Left$(strPath, intPos - 1))
    strPath = Replace$(strPath, """", "")
    
    Debug.Print strPath
    
    ' MsgBox "Path=" & strPath
    
    ' Open folder
    Set fld = FSO.GetFolder(strPath)
    
    ' MsgBox fld.Path
    
    ' Get files in folder
    For Each fil In fld.Files
        ' MsgBox fil
        If UCase$(FSO.GetExtensionName(fil)) = "DEF" Then
           txtCompiler.Text = fil
           Exit For
        End If
    Next
    
    If txtCompiler.Text = vbNullString Then
        LINK  ' Default
    Else
        If MsgBox("Click Yes to apply DLL options over a Standard EXE Project," & vbCrLf & "otherwise click No to let VB handle the usual way.", vbYesNo) = vbNo Then
            LINK  ' Default
        End If
    End If
End Sub
 
Sub LINK(Optional CmdLine As String = vbNullString)
 
If CmdLine = vbNullString Then CmdLine = Command$
If CmdLine = vbNullString Then
    Unload Me
    Exit Sub
End If
 
    Open App.Path & "\LinkerLog.txt" For Append As #1
 
    Print #1, Now & ": ============================================"
    Print #1, Now & ": Command Line Options:   "; Command$
    If CmdLine <> Command$ Then
    Print #1, Now & ": Command Line Options:   "; CmdLine ' Write only if there was a change
    End If
    Print #1, Now & ": ============================================"
    Print #1, vbCrLf & vbCrLf
    
    Close #1
    
    ShellWait App.Path & "\" & LINK_FILE & " " & CmdLine ' i.e.: My SuperShell function
    Unload Me
End Sub

Post on any doubts or errors, i am available! :)

HTH
Neo

EDIT: Had to edit coz 'BookMark #1' line shows a http://www.vbforums.com/images/icons/icon10.gif emoticon where it has the line of code /ENTRY:DLLMain

About questions on this line:

VB Code:

CmdLine = Replace(CmdLine, "/BASE:0x400000", "/BASE:0x10000000")

I have told you that the base address specification of an EXE is 0x400000 which means Windows will first try to start mapping that EXE at the address 0x400000. If there is any other program already mapped at that address Windows will then allocate the next free address say: 0x470216 taking in count all the running programs at various memory addresses.

But DLLs have a different Base Address. Commonly, it is 0x10000000

To test this open a new ActiveX DLL project in VB. Goto Project->Properties and see Compile where the DLL Base Address will be showing: &H11000000

Hmm, now somebody might ask why is it 0x10000000 and not 0x11000000

This is the issue with ActiveX DLLs. http://www.kbalertz.com/kb_138062.aspx <-- This might feed some knowledge on what i am talking about.

If you want to know what is the difference between a regultar DLL and an ActiveX DLL, u must have known COM. But, i cannot explain COM, because it is a BIG BIG issue by itself and to learn about.

Question #1: Now, what is the real reason, that we should create our Win32DLL via a Standard EXE.. What is the need and y not through an ActiveX DLL project?

Answer:
Create an empty ActiveX DLL -> just open a new ActiveX DLL Project and Make 'Project1.DLL' Start->Programs->Microsoft Visual Studio 6.0->Microsoft Visual Studio 6.0 Tools->Depends

Open the File you just created and you will see that even if u haven't written any code or function there are two functions already in the DLL namely DLLRegisterServer and DLLUnRegisterServer

How did these two appear? Because you have created an ActiveX DLL Visual Basic automatically includes & compiles these two functions.. This is part of the compilation process. VB compiler adds this information in the .OBJ file which corresponds to the StartUp Object specified by the Project. This is the reason why we are creating the DLL via the Standard EXE and changing the switch while LINKing.
_________


We will move on to the first point now and see how that works (If you have not seen all my 3 points go here):

Code:

---

/ENTRY:__vbaS

---

I have now come to the point that the above parameter does not tell the VB Linker to include VB Runtimes.. Then Whats the use of the above one?

To know the answer, read on.

This is an extract from the MSDN documentation for VC++ Linker options.. I know that we are not dealing with VC++ LINKer options but this is just basically how every linker works.

Code:

---

mainCRTStartup (or wmainCRTStartup)        An application using /SUBSYSTEM:CONSOLE; calls main (or wmain)

WinMainCRTStartup (or wWinMainCRTStartup)        An application using /SUBSYSTEM:WINDOWS; calls WinMain (or wWinMain), which must be defined with __stdcall

_DllMainCRTStartup        A DLL; calls DllMain, which must be defined with __stdcall, if it exists


If the /DLL or /SUBSYSTEM option is not specified, the linker selects a
subsystem and entry point depending on whether main or WinMain is defined.


The functions main, WinMain, and DllMain are the three forms of the
user-defined entry point.


When creating a managed image, the function specified with /ENTRY must
have a signature of (LPVOID var1, DWORD var2, LPVOID var3).

---

You can find the page here


A linker's main aim is to collect all the .OBJ files and the specified .LIB files along with the language's RUNTIME files. No matter what VB LINK.exe does exactly the same and it includes the MSVBVM60.DLL Runtime DLL (You will see the proof soon)

The /ENTRY option has __vbaS value. This is nothing but a function inside one of those OBJ files.. The VB Compiler decides which OBJ by looking at the Startup Object specified in your project. If it is a form: frmMain then the __vbaS function has code to create the form object and show it eventually! (Have you ever wondered how your default form was loaded and shown?)

Quote:

---

Originally Posted by penagate

I'm going to be n00bish and ask how the runtime library is referenced. Seeing as it is part of the linking process. I looked at the command line arguments for the linker log and there was no mention of msvbm60.dll, So presumably it is part of the .obj file. I am going to try and copy the .obj file out at compile time and disassemble it to have a look. maybe if it is in there then we can add it in so it gets linked with the DLL.

---

It is not the part of the .OBJ file but it is the linking process like i said there.. You may also doubt on the highlighted part below.. This LIB file is LINKED with any VB project. No Matter it is a Standard EXE or an ActiveX DLL

Code:

---

7/19/2005 2:19:57 PM: Command Line Options:  "E:\Dev\Programming
Languages\VB6\Fast TryOuts\VBWin32DLL Hook\stdcall.OBJ"
"E:\Dev\Programming Languages\VB6\Fast TryOuts\VBWin32DLL
Hook\test2.OBJ" "E:\Program Files\Microsoft Visual
Studio\VB98\VBAEXE6.LIB" /ENTRY:DLLMain /OUT:"E:\Dev\Programming
Languages\VB6\Fast TryOuts\VBWin32DLL Hook\test2.dll" /BASE:0x10000000
/SUBSYSTEM:WINDOWS,4.0 /VERSION:1.0  /INCREMENTAL:NO /OPT:REF
/MERGE:.rdata=.text /IGNORE:40 /DLL /DEF:"E:\Dev\Programming
Languages\VB6\Fast TryOuts\VBWin32DLL Hook\StandardDLL.def"

---

To know the proof: I have attached my WIN32DLL done in VB 'test2.dll'. Open that DLL file through Depends, you will see MSVBVM60.DLL in the dependency tree.

Atlast, this means that we can include our Win32DLL in any project, such as VC++ or our own VB Project (obvious)

Questions are welcome!

Quote:

---

Originally Posted by CodeBlock

It is not the part of the .OBJ file but it is the linking process like i said there.. You may also doubt on the highlighted part below.. This LIB file is LINKED with any VB project. No Matter it is a Standard EXE or an ActiveX DLL

Code:

---

7/19/2005 2:19:57 PM: Command Line Options:  "E:\Dev\Programming
Languages\VB6\Fast TryOuts\VBWin32DLL Hook\stdcall.OBJ"
"E:\Dev\Programming Languages\VB6\Fast TryOuts\VBWin32DLL
Hook\test2.OBJ" "E:\Program Files\Microsoft Visual
Studio\VB98\VBAEXE6.LIB" /ENTRY:DLLMain /OUT:"E:\Dev\Programming
Languages\VB6\Fast TryOuts\VBWin32DLL Hook\test2.dll" /BASE:0x10000000
/SUBSYSTEM:WINDOWS,4.0 /VERSION:1.0  /INCREMENTAL:NO /OPT:REF
/MERGE:.rdata=.text /IGNORE:40 /DLL /DEF:"E:\Dev\Programming
Languages\VB6\Fast TryOuts\VBWin32DLL Hook\StandardDLL.def"

---

---

Yep I found that also. I'm also interested in the fact that it becomes possible to create VB apps without using the runtime (To a degree). Would be good for things such as installers. Also if we wrote a lot of our own replacements for the functions in the runtime lib.

Did you try the shell hook and did it work?

I tried it on a hook. I tried to hook Notepad but it causes Notepad to crash when the dll gets attached.

So, it appears that there is something wrong with the dll since I have no problem if the dll is written in C.

Quote:

---

Originally Posted by moeur

I tried it on a hook. I tried to hook Notepad but it causes Notepad to crash when the dll gets attached.

So, it appears that there is something wrong with the dll since I have no problem if the dll is written in C.

---

1. Did you use my Linker Code? Coz i rewrote the whole code!

2. Whats your DLLMain Syntax? Did it look like this?

VB Code:

Public Function DLLMain([HL]hInst As Long, ByVal fdwReason As Long, lpvReserved As Long[/HL]) As Long
   Select Case fdwReason
      Case DLL_PROCESS_DETACH
         ' No per-process cleanup needed
      Case DLL_PROCESS_ATTACH
         ' No per-process initialization needed
      Case DLL_THREAD_ATTACH
         ' No per-thread initialization needed
      Case DLL_THREAD_DETACH
         ' No per-thread cleanup needed
   End Select
   hInstance = hInst  ' This is the App.Instance Parameter
   DLLMain = 1        ' Return 1 on success
End Function

Check the highlighted signature, as specified in the MSDN documentation:

Code:

---

When creating a managed image, the function specified with /ENTRY must
have a signature of (LPVOID var1, DWORD var2, LPVOID var3).

---

3. Can u show your DLL code AND the Injector code?

HTH
Neo

lpvReserved should be ByVal. Not that it matters since it is unused.

I'm getting the code ready for upload now. Just removing any evidence of potentially embarassing past stupid mistakes :)

I use my own linker whick I modified. While playing around I noticed that if the linker runs into an error it exits with no messages. To see the linker messages, you can use the one that comes with C++. Here are the linker options I get.

Code:

---

Command line arguments after modification:

"C:\Documents and Settings\All Users\Documents\VBwin32DLL\dllHook\dllHook.OBJ" "C:\Documents and Settings\All Users\Documents\VBwin32DLL\dllHook\dllHook1.OBJ" "C:\Program Files\Microsoft Visual Studio\VB98\VBAEXE6.LIB" /ENTRY:DllMain /OUT:"C:\Documents and Settings\All Users\Documents\VBwin32DLL\dllHook\dllHook.dll" /BASE:0x10000000 /SUBSYSTEM:WINDOWS,4.0 /VERSION:1.0    /DEF:"C:\Documents and Settings\All Users\Documents\VBwin32DLL\dllHook\dllHook.def" /DLL /INCREMENTAL:NO /OPT:REF /MERGE:.rdata=.text /IGNORE:4078

---

The DllMain syntax is

VB Code:

Public Function DllMain(ByVal hInst As Long, ByVal fdwReason As Long, _
  ByVal lpvReserved As Long) As Long

All should be passed by value not by reference I do know this much since I write C dlls. The return type BOOL penagate points out should be Long, but I couldn't confirm that so I tried both.

I'll upload the code in a couple of minutes

OK, here it is:
The linker, dll and VB test program
The test program call a routine in the dll to try to hook notepad.
It subclasses itself to receive return messages from Notepad.
Right now I've commented out the code inside the Notepad's hook routine to see if I could stop Notepad from crashing

No luck so far.

I'll explain my last couple of posts a bit more, since we all seem to be doing it :)

BOOL along with a plethora of others is defined in windef.h.

Code:

---

typedef int                BOOL;

---

an int in C++ is a 32-bit word which is a VB Long.

However a bool is 1 byte long (as of VC++ 5 anyway) so in VB it would be a Byte.

Since lpvReserved is typed LPVOID this indicates it is a long pointer to an untyped memory space. VB doesn't have these (although I recently discovered you can do some obscene memory tricks using strings as pointers) so we need to pull the pointer value from the stack directly by using ByVal. Of course this is immaterial since being reserved it is never touched anyway.

Same goes for hInst which we do want to use.

If hInst was typed LPVOID it would be a pointer, which it isn't, it is a straight value.

The correct prototype is

Code:

---

BOOL WINAPI DllMain(HINSTANCE hinstDLL,
                    DWORD fdwReason,
                    LPVOID lpvReserved)

---

HINSTANCE is a long handle type.

In either case it needs to be defined as ByVal in VB.

Quote:

---

Originally Posted by penagate

If hInst was typed LPVOID it would be a pointer, which it isn't, it is a straight value.

The correct prototype is

Code:

---

BOOL WINAPI DllMain(HINSTANCE hinstDLL,
                    DWORD fdwReason,
                    LPVOID lpvReserved)

---

HINSTANCE is a long handle type.

---

Ahh, Man! Everyone knows that if u need to extract the pointer u need to change your declaration as .. , ByVal lpvReserved As Long)

But the point is we just need the hInstDLL which can be declared directly as (hInst As Long,...

Why, declare as ByVal hInst and CopyMemory.. lol.. i just pointed out that to see whether moeur's had done it by mistake...

Quote:

---

So, it appears that there is something wrong with the dll since I have no problem if the dll is written in C

---

Why do u always blame the DLL, lol :p

When i Ran your EXE code i had a break point right at the cmdHook_Click and stepped over.. I found out that VB was trying to show some error message highlight as below:

VB Code:

strData = [HL=#3333FF]Space[/HL](dataStruct.cbData, 0)

The error obviously cannot be seen since you have subclassed your code.

Dont know the reason why the error was there.. Working on that now

Ahh, Your EXE doesnot even compile.. :(

Says, Cannot find project or library at that line of code.. and opens up the Reference dialog pointing to a MISSING reference: 'MISSING: Debug Object for AddressOf Subclassing'

One of the latest errors i have ever seen.. lol

HTH

The hInst value is a handle passed by value, there is no question about this.
In fact, if you change it to byref then the hook procedure returns an error because you have an invalid handle

Quote:

---

'MISSING: Debug Object for AddressOf Subclassing'

---

Just remove that from the reference, it isn't needed.

Quote:

---

Originally Posted by moeur

Just remove that from the reference, it isn't needed.

---

Hey, moeur!! I am not a n00b.. lol.. have n't u still understood? I was just pointing out how Visual Basic is reacting differently... When u have a missing reference ( i know that u forgot to remove it while attaching your project ), why should VB complain on the line: strData = Space(dataStruct.cbData, 0)

Oops, i dint put the above line in my previous post.. i was incomplete.. sorry!

Space function accepts only one parameter which is the length of spaces you need. And so VB is supposed to error: Wrong number of arguments. But i was just playing around how VB reacts when u have a missing reference.. hmm, think i should not play around, just misleads to many stuff.. :p

Also, moeur, when u run your EXE press Ctrl+F5 with codes implementing Subclassing.. which makes sure u dont have any compiler error!

And i dont understand your old quote:

Quote:

---

Originally Posted by moeur

The hInst value is a handle passed by value, there is no question about this.
In fact, if you change it to byref then the hook procedure returns an error because you have an invalid handle

---

Nopez, cant you see that any LPVOID is nothing but a pointer which is obviously pointer... You have just given your DLL code having the DllMain as:

VB Code:

Public Function DLLMain([hl]hInst As Long[/hl], ByVal fdwReason As Long, _
  lpvReserved As Long) As Long

which is ByRef.. What are you trying to tell?? You seem to contradict your own code :confused:

Anyway, i will be back with the working code of your Notepad Hook.

Here is the component.

This DLL was first featured in a VBPJ article by Matt Curland about subclassing with VB5. Its main purpose is to allow breaking into and stepping through code that subclasses windows, something not directly supported by VB.

To enable it you would change the compiler directive int cSubClass module to

VB Code:

#Const DEBUGWINDOWPROC = -1

However, set it back to zero before compiling.

For now though, you can even disable the subclassing until we fix the dll problem. Just comment out this code in the form module cmdHook_Click event

VB Code:

'subclass this form to receive callback messages
    If Not SubClass.Enable(Me.hwnd) Then
        MsgBox "Subclassing Failed"
        Exit Sub
    End If

Quote:

---

VB Code:

Public Function DLLMain(hInst As Long, ByVal fdwReason As Long, _
  lpvReserved As Long) As Long

---

Whoops, my mistake, I posted code I was using to test different configurations. It should be

VB Code:

Public Function DLLMain(ByVal hInst As Long, ByVal fdwReason As Long, _
ByVal  lpvReserved As Long) As Long

The hInst value passed to DllMain needs to be passed as is to SetWindowsHookEx

Code:

---

HHOOK SetWindowsHookEx(     
    int idHook,
    HOOKPROC lpfn,
    HINSTANCE hMod,
    DWORD dwThreadId
);

---

it's a handle (which is a pointer) and this function needs that pointer.

I don't know why the code is giving a breakpoint at that line. Again we don't need subclassing now so let's just disable it for the time being.

Ok, SetWndProcHook Works fine, and notepad stils stays on and removes hook correctly, BUT WndProc inside the DLL was never called :(

What might be the reason?

This is my DLL code

Did you move yor mouse over the top of notepad to generate a message? That's when it crashes for me.

PS: It's obvious you're not a NOOB, but I have to ask.:)

Quote:

---

Originally Posted by moeur

Did you move yor mouse over the top of notepad to generate a message? That's when it crashes for me.

PS: It's obvious you're not a NOOB, but I have to ask.:)

---

LOL, You got to be kidding me... I minimized, maximized, Type some message, Selected them through mouse, and did so many stuff but Notepad was stubborn that it wont crash, and the VB DLL was stubborn that it will not receive any message for the actions i did :p

Is your WndProc getting called correctly?

Also, did u take a look at my DLL?? My DLL has the following WndProc Code:

VB Code:

Public Function SetWndProcHook(hWndVB As Long, dwThreadId As Long) As Boolean
    If IsHooked Then
        SetWndProcHook = False
        'MsgBox "Don't hook CALLWNDPROC twice or you will be unable to unhook it."
    Else
        Open "DLLLog.txt" For Append As #1
            Print #1, Now & " : Going to Set a New hook for dwThreadId=" & dwThreadId
        Close #1
 
        hHook = SetWindowsHookEx(WH_CALLWNDPROC, AddressOf WndProc, hInstance, dwThreadId)
        If hHook = 0 Then
            SetWndProcHook = False
        Else
            hWndCallback = hWndVB
            IsHooked = True
            SetWndProcHook = True
        End If
    End If
End Function
 
Public Function WndProc(ByVal uCode As Long, _
    ByVal wParam As Long, lParam As CWPSTRUCT) As Long
 
    Dim strMessage As String
    Dim OutData As COPYDATASTRUCT
    Dim vParam As CWPSTRUCT
 
    Open "DLLLog.txt" For Append As #1
        Print #1, Now & " : WndProc Called: uCode=" & uCode & ", wParam=" & wParam
    Close #1
 
        Select Case uCode
        
            Case HC_ACTION
''                If lParam.message = 0 Then 'just check WM_NULL messages for now
''                  strMessage = "MSG:" & Hex$(lParam.message) _
''                             & "    HWND:" & Hex(lParam.hwnd) _
''                             & "    WPARAM:" & Hex(lParam.wParam) _
''                             & "    LPARAM:" & Hex(lParam.lParam) _
''                             & "    CURRTHREAD:" & Hex(wParam)
''
''                  With OutData
''                    .lpData = StrPtr(strMessage)
''                    .dwData = 0
''                    .cbData = Len(OutData)
''                  End With
''                  SendMessage hWndCallback, WM_COPYDATA, 0, OutData
''                End If
            Case Else
        End Select
    
    
    WndProc = CallNextHookEx(hHook, uCode, wParam, lParam)
End Function

In the DLLLog.txt:
7/21/2005 4:10:56 AM : Going to Set a New hook for dwThreadId=2132
is displayed.. but no entry is displayed for WndProc Called :(

Whats the prob?

Just finished looking at your dll,

The problem is that you can't put file access statements into the dllMain or the dll won't attach. This is because those libraries aren't loaded.

Comment out those lines in DllMain and you will see Notepad crash crash crash...

This at least tells us we are attaching the dll, but something is wrong with the WndProc routine.

OK, here is more info
change WndProc to just

VB Code:

Public Function WndProc(ByVal uCode As Long, _
    ByVal wParam As Long, ByVal lParam As Long) As Long
    Dim i As Integer
    WndProc = 0
End Function

This allows the dll to attach to Notepad and does not crash Notepad.

Now, just add something simple and it crashes Notepad.

VB Code:

Public Function WndProc(ByVal uCode As Long, _
    ByVal wParam As Long, ByVal lParam As Long) As Long
    Dim i As Integer
    
    For i = 1 To 10
    Next i
    
    WndProc = 0 'CallNextHookEx(hHook, uCode, wParam, lParam)
End Function

So we cannot use any VB code inside the routine. This makes sense since non of the libraries or com objects have been initialized.

Quote:

---

Originally Posted by moeur

Just finished looking at your dll,

The problem is that you can't put file access statements into the dllMain or the dll won't attach. This is because those libraries aren't loaded.

Comment out those lines in DllMain and you will see Notepad crash crash crash...

This at least tells us we are attaching the dll, but something is wrong with the WndProc routine.

---

YUP, It does now ... lol :p

I think I've gone full circle. A while back I was trying to find out how to make a callback from one thread in C++ dll to another thread in a VB exe. Well I never solved the problem and it has something to do with initializing the com objects VB need that are stored on a per thread basis.

Here is that thread
http://www.vbforums.com/showthread.php?t=327589

I found a way to do it without using a hook at all. Instead, subclass your form and call RegisterShellHookWindow() to receive the shell notifications.

Attached is a demo which monitors to see if Notepad is open.

Quote:

---

Originally Posted by penagate

I found a way to do it without using a hook at all. Instead, subclass your form and call RegisterShellHookWindow() to receive the shell notifications.

Attached is a demo which monitors to see if Notepad is open.

---

Just read this now, very interesting! Great job

Hmmm... Timer, so many misconceptions. Look in my signature for Help with Timers.

Timers are not bad. that like saying that your car is bad because it can't haul 10 tons of dirt. The right tool for the right job.

Quote:

---

Originally Posted by penagate

I found a way to do it without using a hook at all. Instead, subclass your form and call RegisterShellHookWindow() to receive the shell notifications.

Attached is a demo which monitors to see if Notepad is open.

---

This code is great, can somebody please turn this into vb.net code? I am having a hard time converting.