…unlikely.
And make sure the .dll files you downloaded have READ access, in case you haven’t’ already. That could cause a “The application failed to initialize properly” error.
Nope, still locks up after pressing Start. Upon loading, however, the box is now populated with the following (before pressing anything):
BEFORE pcap_findalldevs
BEFORE displaying devices
Device
1
Description
\Device\NPF_{5DC3CBB8-B922-42F0-ABDB-ED06ECA827D5}
NET IP/1394 Miniport
Device
2
Description
\Device\NPF_{7465BDE4-63E4-4B03-AB85-0DC573D8D54D}
National Seminconductor Corp. DP83815 10/100 MacPhyter 3v PCI Adapter
=====================================================
Thanks again caphis
The very odd thing is the text that populates the screen initially is from code that was cut 'n pasted from the beginning of the START routine. The exact same code.
It’s kind of like just the basic event handler isn’t working. Could this be because we have different mfc70.dll files? (they are exact same length, though)
If you feel like it, make a backup of yours, and try it using mine from http://users.adelphia.net/~tlaplaca/mfc70.dll.
Thank you again.
And I know you had to type the output by hand, which is more work that you should have had to do.
No go that time, either. Infinite loop somewhere? (don’t have the source code anymore)
All in the name of science. 
I added a simple dialog first thing in the START handling. If it still locks after hitting START, and no dialog, the problem is somehow between pressing the START button but before the START button handler is run. Of course, I have no clue how to fix that.
START button Pressed.
Oh-- and, same lockup afterward. Looks like we’re making progress, though.
The dialog is shown? Wow, that surprises the hell out of me. I was sure it wasn’t even getting into the button handling code.
This is indeed great progress. The problem almost certainly has to be in this code, where I get the ClistBox object so I can send output to it.
// get access object for ListBox
CWnd* pListWnd = GetDlgItem(IDC_LIST4);
ASSERT(pListWnd);
// CListBoxes derive from CWnds, so we can downcast the pointer to get a pointer to the listbox, and then use its methods
CListBox* OutBox = dynamic_cast<CListBox*>(pListWnd);
ASSERT(OutBox);
Strange things:
- This same code works fine for you when it runs in the Init (to display adapters)
- The ASSERTs aren’t being thrown
- IT WORKS FINE FOR ME!!! ARRGHH!!!
Maybe I’ll make another that pops another dialog after this code, just to be sure it’s this stuff.
Thanks again.
OK, made a new one with a dialog after that suspect code.
http://users.adelphia.net/~tlaplaca/sps13.exe
Actually, skip 13, try this:
http://users.adelphia.net/~tlaplaca/sps14.exe
This may actual have a fix, in that you’ll be able to exit with the EXIT button. Likely, it still won’t display packet data. (likely it ain’t fixed either…)
Loads up as normal, press Start -> START button Pressed dialog appears, After Getting ListBox Object dialog appears, “START clicked” and “(after getting ClistBox object)” added to listbox.
No hanging this time, but no packets, either. Keep up the good debugging. 
Woohoo!!!
There were loops in that code that seemed to be able to handle timeouts (it’s code copied from the WinPCap website that I modified), but apparently not. I added some PeekMessage code into these loops.
Seems obvious now…
I bet your active connection is the second one, right? The prog is still hard coded to the first.
Now seems a good time to start working on the dialog to prompt the user for which network connection to sniff.
Thanks man, I think I turned the corner. Couldn’t have done it without you.
I believe my active connection is the second one, yeah. Nice job!
When you finish the selection code for choosing an adapter, I’d love to try that one out.
Revtim, with your .14 release, I can see that it’s focusing on the Bluetooth PAN adapter. Seeing that, I decided to start some BT activity – SPS picked up and reported those packets, so it does work. Good job! After you do the device selection dialog, I’d be happy to test it for you also.
Thanks all.
I’m having some trouble with accessing a control on another dialog, though.
The 1st line refrences the new dialog I made, the prompt for the interface. The dlg.DoModal(); command works fine popping it up (which is only there now for a test).
But, I need to to access the IDC_COMBO1 ComboBox in the new dialog, to populate it with the interface choices. That’s what the last line is attempting to do, but it fails in some ASSERT deep in the generated code somewhere.
What surprised me is that dlg is NULL after the first line, which makes me think it odd that the dlg.DoModal() works. But looking at other progs, I think that’s OK, at least for DoModal.
Searching on the net, I couldn’t find any other way I could shoehorn into my prog. This method was indeed refrenced by somebody, and it seems logical, except for dlg being NULL.
I also tried
with no difference.
caphis, do have any idea what I’m doing wrong?
Hmm… I’m not sure, but how about trying it backwards? That is, set a hidden property in the initial form to hold the list, then, in the new dialog, load the values from it?
Does that make any sense?
But wouldn’t I have the same problem in the new dialog, trying to access the control in the initial dialog?
I also thought about doing it in the intialization of the new dialog, but it doesn’t have an OnInitDialog function, and I cannot see how to add one. When I right click it, the “Add New Event Handler” function is ghosted.
OK, now I think it’s failing because the dialog’s controls don’t exist until DoModal(), and are gone when it’s done.
I think the solution is to do it in OnInitDialog of the new dialog, but for some reason that handler does not exist. Maybe I need to make a new dialog.
Hey, I was able to manually add an OnInitDialog() to the new dialog (and it actually gets called), so I’ll just start using that.