Prev: determine style of a mshflexgrid col
Next: Can I use/reference an OCX in a different way?
From: Nobody on 2 Nov 2009 14:44
"Rick Rothstein" <rick.newsNO.SPAM(a)NO.SPAMverizon.net> wrote in message
news:OBJfuH$WKHA.3720(a)TK2MSFTNGP02.phx.gbl...
>> On the bright side, it's clear that MS intends to
>> support VB for a long time to come. I downloaded
>> and unpacked the installer just to see what's in
>> there. Looking at the version info. on the properties
>> tab for the first control, ComCt232.ocx, I see under
>> Comments: March 24, 19109. :)
>
> Our VB6 programs will continue to work for the next 17000+ years... that
> is good to know. I'll bet none of the VB.NET versions will be guaranteed
> to work anywhere near that long. I guess that proves, in the long run,
> that VB6 is the superior product in Microsoft's eyes.

While on the subject, VB 2010 Beta executables have version 4.00(Windows 95)
marked in the EXE header, unlike 2008 which uses 5.00(Windows 2000). I must
be dreaming or this is a bug :-)


From: Nobody on 2 Nov 2009 16:16
I just tested the December 2008 version of the update to see how it affects
Winsock, in particular, "Load Winsock1(1)". In the article, it mentions one
of the bugs that was introduced is that using "Controls.Add" would generate
an error. I found that using Load statement is not a problem. I didn't test
"Controls.Add" because I don't use it.

I used Windows 2000 Server clean install without service packs, plus VM
Additions(To enable copy and paste and file transfer), then copied
MSWINSCK.OCX 6.1.98.13(Dec 2008) to system32 folder and registered it, then
ran my EXE, compiled with VB6+SP5. I used the run time that came with
windows. The program ran without errors. VB6 itself was not installed in
this VM. Here is my code:

Option Explicit

Private Declare Sub OutputDebugString Lib "kernel32" Alias _
"OutputDebugStringA" (ByVal lpOutputString As String)

Private Sub DebugPrint(ByRef MSG As String)
Debug.Print MSG
OutputDebugString MSG & vbCrLf
End Sub

Private Sub Command1_Click()
1 On Error GoTo Command1_Click_Error

2 Load Winsock1(1)
3 Winsock1(1).Protocol = sckUDPProtocol
4 Winsock1(1).RemoteHost = "localhost"
5 Winsock1(1).RemotePort = 8000
6 Winsock1(1).LocalPort = 8000
7 Winsock1(1).Bind 8000
8 Winsock1(1).SendData "Test"

ExitSub:
9 DebugPrint "IP: '" & Winsock1(1).RemoteHostIP & "'"
10 Exit Sub
Command1_Click_Error:
11 MsgBox "Form1:Command1_Click:" & Erl & vbCrLf & "Error " & _
Err.Number & ": " & Err.Description
12 Resume ExitSub
End Sub

Private Sub Form_Load()
DebugPrint App.Title & " started at " & Time
End Sub

Private Sub Form_Unload(Cancel As Integer)
Winsock1(1).Close
End Sub

Private Sub Winsock1_DataArrival(Index As Integer, _
ByVal bytesTotal As Long)
DebugPrint "Winsock1_DataArrival: IP: '" & Winsock1( _
1).RemoteHostIP & "'"
End Sub



Output:

KB957924Test1 started at 4:05:35 PM
IP: ''
Winsock1_DataArrival: IP: ''

I know that RemoteHostIP is shown blank, but I got the same result in XP+SP2
with SP5 version of the OCX(version 6.0.89.88). I assume this is a known
problem. I tried googling it, but didn't find a solution. I tried TCP
protocol, and the connection is established according to TCPView, but
RemoteHostIP is still blank. I haven't tested my real application with this
rollup update, but I will in the next few days, and post the result here.



From: Roark on 11 Nov 2009 10:37
Thank you Rob!

My story: A server application I coded 5 years ago worked flawlessly
UNTIL I applied KB957924-V2 last night. Now the application throws two
errors:

1). The final digit of the RemoteHost is trucated by one digit (ie,
".123" becomes ".12"), but this truncation only occurs about 1 time out
of every 5.

2). The RemoteHostName occasionally returns garbage for hosts that are
not resolveable to names. (Note this used to return a blank/zero-length
string very reliably).

I wanted to share these two things with the group so nobody else is
forced to spend a night banging and crashing like I did. Now I need to
figure-out how to ungoofify (is that a word?) the "help" MS has given
me. :)

If it wasn't for Rob's post, I'd still be convinced I had a hardware
issue. Thanks to Rob and Google, I now realize I'm not alone and
milking without a bucket!

Remove the obvious impediments to email me. :)

*** Sent via Developersdex http://www.developersdex.com ***
From: Nobody on 11 Nov 2009 10:52
"Roark" <Roark(remove)7(a)aol.(hi_mom)com> wrote in message
news:uo0BzTuYKHA.3712(a)TK2MSFTNGP06.phx.gbl...
> Thank you Rob!
>
> My story: A server application I coded 5 years ago worked flawlessly
> UNTIL I applied KB957924-V2 last night. Now the application throws two
> errors:
>
> 1). The final digit of the RemoteHost is trucated by one digit (ie,
> ".123" becomes ".12"), but this truncation only occurs about 1 time out
> of every 5.

Do you mean RemoteHostIP property?

> 2). The RemoteHostName occasionally returns garbage for hosts that are
> not resolveable to names. (Note this used to return a blank/zero-length
> string very reliably).

Do you mean RemoteHost property?

You may want to try SocketWrench freeware edition, which is decent and
reliable, and it includes commercial use.

SocketWrench:
http://www.catalyst.com/products/socketwrench/

It only works on Windows 2000+. Even though they say the free version might
work in Windows 95/98, it didn't register in Windows 98 when I tried it. It
needs API that exist in Windows ME+. The standard version requires Windows
2000+ according to the FAQ.

When downloading, you don't need to fill any information if you don't want
to, just click on "Continue" button.


From: Roark on 11 Nov 2009 11:03
Update:

I was able to confirm the update from MS was causing my problems.

The fix: I swapped the "new" mswinsck.* files for some I pulled from a
different (non-upgraded) machine. The issue I had with both the
truncated IP address and the occasional garbage in the host name both
resolved after the swap.

If anyone cares, swapping the following three files for older editions
cured the problem:

c:\windows\system32\mswinsck.oca
c:\windows\system32\mswinsck.ocx
c:\windows\system32\mswinsck.dep

FWIW, the platform I'm on is a Win 2003 Enterprise x86. YMMV.

Remove the obvious impediments to email me. :)

*** Sent via Developersdex http://www.developersdex.com ***
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: determine style of a mshflexgrid col
Next: Can I use/reference an OCX in a different way?