C / C++ / MFC

JudyL_MD30-Oct-07 2:27

JudyL_MD

30-Oct-07 2:27

The size of your message pieces depends on your communication medium. You need to experiment and find the balance between transmission time and the overhead to prepare a message segment. Also, you'll need to implement some kind of handshake to handle corrupt message pieces.

If you're that concerned about corruption, do some investigating about Error Correcting Codes.

Judy

Mark Salsbery30-Oct-07 7:15

Mark Salsbery

30-Oct-07 7:15

What protocol are you using?

If it's TCP, you don't need to worry about CRC.
You probably won't be able to send that much data in one
send() call though Smile | :)

Are you encrypting the data or just worried about successful delivery?

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Russell^'30-Oct-07 7:33

Russell^'

30-Oct-07 7:33

Thank you for you reply Big Grin | :-D

I'm using socket with TCP protocol.
I don't need to encript the data, my only problem is the success of this trasmission.
I know that usually at low level the data is cheched with CRC (as in TCP) ... but it works only on small frames (like 20/50 Bytes, not more, as my opinion).
I repeat that I'm not expert on Winsock, so I don't know if my message is splitted in more frames and then tranmitted. (do you know this? Confused | :confused:

)
To solve by myself the problem I was thinking to split the big message in more little messages. Then the only dubt is the length of the messages.
As you point send() function probally needs more shorter data (this probally is related on what I mean before)

Then, finally, when every little messages is received I have to check if the file is corrupted. But then I need an algorithm different from CRC (elseway probally this check will fail)...so....what use?
I found MD5, I like it Hmmm | :|

. Do you have any suggestions on this? Big Grin | :-D

thanks for your time

Russell

Mark Salsbery30-Oct-07 8:03

Mark Salsbery

30-Oct-07 8:03

Russell' wrote:
I'm using socket with TCP protocol.
I don't need to encript the data, my only problem is the success of this trasmission.

Why worry about this then?

Yes, the TCP protocol will split your data into "frames". The network may further split those
frames. The protocol will also check for successful transmission, resend when necessary, etc. until all
data sent transmits successfully.

I'm not sure what you hope to gain by splitting into smaller units yourself.

I would let TCP do its thing. It's a very reliable protocol.

As for the send() function (and recv() as well), how much you can do at one time
depends on the socket's buffer size and how much room is left in that buffer.

Nothing changes at the application layer of the protocol stack however - you should always be
calling send() and recv() enough times until all data is sent or received.

When sending, for example (receiving is very similar)...

char *pNextByteToSend = ;
int nBytesToSend = ;

while (nBytesToSend > 0)
{
   int nBytesSent = ::send(socket, pNextByteToSend, nBytesToSend, 0); 

   if (SOCKET_ERROR == nBytesSent)
   {
      // error occurred
      int sockerr = ::WSAGetLastError();

      if (sockerr != WSAEWOULDBLOCK)
     {
         // handle error and exit while() loop
         break;
     }
   }

   pNextByteToSend += nBytesSent;
   nBytesToSend -= nBytesSent;
}

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

Russell^'30-Oct-07 8:30

Russell^'

30-Oct-07 8:30

Great

Then you solved all my problems/dubts (I hope Unsure | :~

).
Thank you very very much
Rose | [Rose]

Russell

PC Controlled Relay Board

Mark Salsbery30-Oct-07 8:06

Mark Salsbery

30-Oct-07 8:06

And yes you could use MD5 to check the integrity of the entire data sent.

That would be part of the application layer (your code) of your protocol,
not TCP Smile | :)

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

thes3cr3t130-Oct-07 2:06

thes3cr3t1

30-Oct-07 2:06

http://www.quasarelectronics.com/3165.htm[^]

Hey there,

Im relativly new to c++ and looking for a little advice,im interested in buying a PC Controlled Relay Board (Link above) that comes with its on software,however the website in question state's that it is possible to write your own software for the relayboard using a DLL from http://www.logix4u.cjb.net[^]now i have no experience in parralel port coding and was wondering how much of a mammoth task this would be.

Here is my concern - As you can see the board has 8 relays that can be independently controlled with software via the parralel port, Well how do i find the On/Off commands that will have to be called from my DLL and sent to the relay board to control each individual relay on the board?

Any advice would be greatly appriciated.
Thankyou for your time.
Chris

Re: PC Controlled Relay Board [modified]

Rhymhoont30-Oct-07 4:41

Rhymhoont

30-Oct-07 4:41

I don't have experience with that board you have listed but a while back I wrote a C program that controled 36 relays. In that case it was simple calls to functions supplied in the manufacturers' DLL. Basically I sent their function a bit pattern of the relay's I wanted on or off.

On initializing the app, you would set up the interface between the functions and the port / hardware. Just hope that their DLL si writen well.

I would have to go look in my files, but I seem to remember it was Houston Instruments or something. Not Texas Instruments.

In any case. the controling of the board from my code was the easiest part of the app.

-- modified at 10:52 Tuesday 30th October, 2007

I checked, it was National Intruments: http://www.ni.com

how to get Row count in MS flexgrid

panthal30-Oct-07 2:06

panthal

30-Oct-07 2:06

hi,
i'm using a flex grid in my project.
i don't know how to get the no of rows in the MS flexgrid

thanks
panthal

Re: how to get Row count in MS flexgrid

chandu00430-Oct-07 2:17

chandu004

30-Oct-07 2:17

yourgridvariable.GetRows();
will do for you.

--------------------------------------------
Suggestion to the members:
Please prefix your main thread subject with [SOLVED] if it is solved.
thanks.
chandu.

Re: how to get Row count in MS flexgrid[solved]

panthal30-Oct-07 3:24

panthal

30-Oct-07 3:24

thank u very much chandu,

i searched this function in more sites,

but i didn't get,
thank u

panthal

Deleting session cookies

JanakaAtu30-Oct-07 1:27

JanakaAtu

30-Oct-07 1:27

Hi,

We are using webbrowser control within our MFC desktop application to navigate different web applications. Some of these applications having session based cookies which are valid until the browser is closed , if acessing from iexplorer.

But our desktop application having it's own session management logic, each time it logs-out and login it creates a new instance of browser control. And what we found was even though the browser object is being released every time, session cookies remains valid until we exit the desktop application.

We found that the WinInet API having some API for cookie management , but we could'nt find any direct API call to delete session cookies of a process.

Can somebody please give us answers for following questions,

1. How can we filter the session cookies from InternetGetCookies() function?

2. Is there any API we can use to delete session cookies?

Thanks,
Janaka

setting no of lines in richedit conroll

aamir ali30-Oct-07 1:12

aamir ali

30-Oct-07 1:12

How to fix no of lines in richedit controll or maximum numbers of characters in richedit controll

Re: setting no of lines in richedit conroll

KASR130-Oct-07 1:26

KASR1

30-Oct-07 1:26

Try with LimitText(number of chars) method..

DLL newbie question [Solved]

Nelek30-Oct-07 0:32

30-Oct-07 0:32

Hi all,

I am embrassed about ask this but... (in VC++ 6) when I create a new project to make a DLL I choose: MFC Application wizard (DLL) and in the dialog that comes there are 3 different types (on German, I write them with what I think they mean).

1) Standard DLL mit verknüpfter MFC-Bibliothek
Standard DLL with associated/linked MFC-Library

2) Standard DLL, gemeins. MFC-DLL verwendend
Standard DLL, MFC-DLL shared usage

3) Erweiterungs MFC-DLL, (nur mit and. MFC-Anw.)
Expansion/extension MFC-DLL, (only with another MFC-Application)

Can someone explain me what is different depending on the selected option?

I want the dll to be used by my programm, I don't care if it is portable for other applications. It is going to be dinamically linked to allow the use of its functions only when the DLL is present in a system.

(Sorry, but neither German nor English are my mother languages and I don't understand them perfectly, it is furthermore going to be my first DLL)

-- modified at 8:59 Tuesday 30th October, 2007

Greetings.

--------
M.D.V.

If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?

Help me to understand what I'm saying, and I'll explain it better to you

Wink | ;)

Nelek30-Oct-07 1:23

30-Oct-07 1:23

At the moment, with this is enough for me. My application is MFC-Win32 and the dll should work with it, no matters what happens with other programms. Furthermore, I think my boss will be glad if my dll gives problems to be used in other applications Wink | ;)

:P

What I need to do in the DLL is to take some parameters of my Document, and interact with external CFiles (read, write, delete) and with a third party DLL (statically linked in my project with a *.lib and a *.h)

So the best option for me is the 3rd one, isn't it? Or should I choose the 2nd one (selected by default)?

jhwurmbach30-Oct-07 2:32

jhwurmbach

30-Oct-07 2:32

Nelek wrote:
What I need to do in the DLL is to take some parameters of my Document, and interact with external CFiles

So you need MFC linked to it anyway.
You can choose the shared MFC variant.

Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"

Nelek30-Oct-07 2:59

30-Oct-07 2:59

Thanks

Phil J Pearson30-Oct-07 1:28

Phil J Pearson

30-Oct-07 1:28

If your main application[s] (the one[s] that will use the dll) is/are MFC then you can choose any of the three. If you want to use the dll from non-MFC applications then you're limited to 1 or 2.

In my view you're probably better sticking to 1 or 2 anyway. Shared MFC DLL is usually the sensible option but there are occasionally circumstances where that creates untold hassle and it's easier to use static MFC linkage.

In summary: if your requirements are fairly straightforward then go for standard dll with shared MFC dll; if things might get complicated go for standard dll with static-linked MFC. (You can easily change between the two if necessary). In either case the calling app does not have to use MFC, but it can.

Phil

The opinions expressed in this post are not necessarily those of the author, especially if you find them impolite, inaccurate or inflammatory.

Nelek30-Oct-07 1:43