Using sockets in VB without a silly OCX control

phaxx

Subject says it all really.

Looking for some code I can put into my app so I don't have to go through all the rubbish of installing/registering an OCX and all that.

phobos

K,

The WinSock component comes with the VB environment. All you have to do is use it.

It's sooo easy, my kitten uses it all the time

;-phobos-)

phaxx

No no no no, that's exactly what I don't want.
I want some CODE, not a damn clumsy OCX. I want to be able to forget about files my app is dependant on and put as much as possible into the executable itself, so I only have to worry about the vb runtime dll and the executable. The standard winsock ocx is NOT present on all windows installs, so I can't use it.

Ta anyway.

phobos

Phaxx,

Stop for a sec, you're messin with my head. If I'm not mistaken, when you finally deploy your application it will have it's own installation routine, right?. The installation routine will install the program and it's dependancies on the client machine. It will actually do all the registry entries for you (which is handy).

I can simply guess that you are making the EXE on your machine and then testing it, right?. Then you are thinking that "Of course it will run on my machine, coz I created it here, but how will it run elsewhere?", yeah?. Ok the next step is to use VB's Package and Deployment tool. You start off by pointing it to your VBP (VB project file), and follow the wizard from there. During the process you will be asked if you want to package any dependancies etc. Say YES.

I don't like seeing ppl re-inventing the wheel, it slows the software industry down, and makes things more difficult for the induvidual. If the prewritten functionality is already encapsulated in to an available component, that is free, you would be mad to go writing your own code. But if you are still determined to write the whole thing from scratch, do it in a proper language, like C/C++ or Java.

Hopefully helpful!,

;-phobos-)

phaxx

Nah, this is for me, little apps for my network, without installers. Things I can just run over the network without any screwing about - I run it, it works, end of story. No installer, no reboots, it just works.

As for reinventing the wheel, well the functionality I want is NOT available, as far as I can see, so that's why I'm asking you.

I don't see how you can compile the winsock code into a c/c++ app but VB can't do this...

My little c++ knowledge won't do for what I need to do, there's just so much you need to know to even open a window, let alone put components in it. I'm trying to write these apps to save me time, and although I intend to become proficient in c/c++ under windows, what I want to do now is just get it working in VB first.

Was a mistake to learn VB first, I suppose.

The Corinthian

<font face="Verdana, Arial" size="2">Originally posted by phaxx:
Was a mistake to learn VB first, I suppose.</font>

Well you gave up quickly

Depends on what you want to do. What functionality are you looking for? You could use a shell net command from VB or instanciate the Inet dll. If all the machines this will be running on are using IE5+ and you're looking for a way to access HTTP, you could also use the XMLDOM that would be present for requests/responses.

Regardless of OCX/code, if winsock is not present, you won't be able to access it, even if you have the code.

---

"Just because I'm evil doesn't mean I'm not nice." - Charlie Fulton

Kix

If you truly insist, there's nothing, I suppose, to stop you declaring all the WinSock functions you want to use in VB and accessing them directly. This sort of thing:

declare function WSAStartup lib "Ws2_32.dll" (ByVal wVersionRequested as Long, ByRef lpWSAData as WSADATA) as Long

Note three things here:

1. That piece of code is off the top of my head and untested - it might or might not be correct. Getting it right will take time and effort for each fn.
2. Already, with just one fn declared you'd have to define a new struct WSADATA in VB to match the one in Winsock.
3. You might want to use "Winsock.dll" instead of "Ws2_32.dll" for generality.

If you decide to go down this path, good luck to you. I've linked VB to DLLs before and it can be quite exhuasting getting the calls right, especially if you have lot of them.

K

phaxx

I found it!

http://www.vbip.com/winsock-api/template/template-01.asp

bonkey

<font face="Verdana, Arial" size="2">Originally posted by phobos:
I don't like seeing ppl re-inventing the wheel, it slows the software industry down, and makes things more difficult for the induvidual. If the prewritten functionality is already encapsulated in to an available component, that is free, you would be mad to go writing your own code. </font>

Generally, I'd agree with you phobos, but in this case I'm siding with Phaxx. See, re-inventing the wheel is a bit dumb, but so is using the wrong wheel.

OCX's have some great purposes, but were designed to provide graphical widgets. COM DLLs should be used when graphical widgets are not needed. Classes should be used when app-independance is not needed.

Access to the winsock API via an OCX is one of the most god-awful, inefficient, overweight ways of going about it. Yes, it may be simple, but thats only a partial excuse.

For example, I have an FTP class which lets me use VB commands which more or less mirror the real ftp commands. It is faster, more reliable, simpler to use, and lighter than the OCX which MS give you to do the same thing. Oh - and it supports aftive and passive ftp, which means its also more powerful.

Was this reinventing the wheel? I dont think so.

You will generally find that any OCX which does not actually provide a graphical widget (data-binding, Winsock, etc.) is almost universally loathed by VB programmers as being a bad solution, and with a little work will generally find some nice bloke who's already written the replacement lightweight, faster class.

If I had to go write it myself, I would consider it. If someone else has written the lightweight replacement, then I'm all for it. It avoids crappy issues like OCX version problems (which are rife), forward compatability, and so on.

jc

phobos

I totally agree jc, but I assumed that this person wanted the quickest and easiest sollution. He did say that the program wouldn't be publicly released, and that it would simply run over his home LAN. So I don't see what's wrong with using the simple OCX that MS supplies.

I know, I know!, that it may not perform as well as what you have suggested. But big toss, when you want something quick that nobody else is probably going to see or use.

To me that type of project is a simple utility (I have loads of them). I never went to any trouble creating them. I never had to rummage web sites to find a better sollution. I know it would be handy for a learning experience. But when you need to buy a car, why save up for a ferarri.

IMO anyway!

;-phobos-)

tails_naf

Hi,
I got a quick messsage for any C/C++ programmer s out there. have any of you tried using sockets under windows / MSVC?? if so please help me - whenever i try to make a program that communicated over tcp/ip say over the internet, the program's always loose synch / get confused. I THOUGHT the idea of windoes sockets and the tcp protocol built in made the transport of info pretty safe, but when i try it, it works fine when im using my own pc as the server and client, but whn i try ot over a netowrk, it sometimes works somtimes fails. It also seems that any data i want to send accross must be split up into very small chunks - why is that?
can anyone give me a quick code example of two-way communication that works for (possibley) large buffers of data?
Cheers guys!!!

p.s. i dont check the boards so often, so if you could email it to me:
tails_nafXXX@yahoo.com

(XXX is a spam block)

Typedef

about the small chunks thing imagine this right,

char somearray[64];

recv(skfd,somearray,sizeof(somearray),0);

on your last recv assuming you received 3 bytes would'nt you have and array with 3 bytes of information you wanted and 61 bytes of information that was from the last read?

so if you used and array of say

char somearray[1];
FILE*file;
file=fopen("somefile",a+);
int a;

while(1)
{
a=recv(skfd,somearray,sizeof(somearray),1);
if(a==0)
break;
fwrite(somearray,sizeof(somearray),1,file);
};
your file should have all the bytes it wanted and nothing superflous to it right?

C/C++ kicks vb's ass ok?
QED