C / C++ / MFC

Re: facing problem on Listing files in List box Control

20-Jan-09 1:21

Do you mean that you run a loop looking for the files, when you find one you add the path to the list, but the list only gets redrawn once your loop is done thus all your hits appear at once? If so, you have 3 options i can think of right now:
1. do the search in a different thread and send/post your hits towards the GUI thread
2. do your search with a timer
3. do your search in idle-time (when your GUI thread has no messages to process)

p.s: You could also try simply forcing your list to be redrawn in your loop with e.g. using RedrawWindow, but that would be an ugly solution.

> The problem with computers is that they do what you tell them to do and not what you want them to do. <

m_mun20-Jan-09 2:02

m_mun

20-Jan-09 2:02

Thanks for your reply. Yes, I have used it in loop, that's why the problem arise

Re: facing problem on Listing files in List box Control

krmed20-Jan-09 2:03

krmed

20-Jan-09 2:03

Another option you can do is within your loop, when you find a file you are most likely doing

m_ListBox->AddString(xxxx)

Immediately after you do the AddString, you can add

m_ListBox->UpdateWindow()

and that will cause the list box to show the new data.

Hope that helps.

Karl - WK5M
PP-ASEL-IA (N43CS)
PGP Key: 0xDB02E193
PGP Key Fingerprint: 8F06 5A2E 2735 892B 821C 871A 0411 94EA DB02 E193

Problem in ShellExecuteEx.

SNI20-Jan-09 1:01

SNI

20-Jan-09 1:01

Hi,
I want to launch outlook using ShellExecuteEx and I am able to launch it. But I want to pass file (mydoc.doc) as a parameter to it. So that it will open an outlook evelop and attach this file to it.

SHELLEXECUTEINFO shExecInfo;
shExecInfo.cbSize = sizeof(SHELLEXECUTEINFO);

shExecInfo.fMask = NULL;
shExecInfo.hwnd = NULL;
shExecInfo.lpVerb = NULL;
shExecInfo.lpFile = "OutLook";
shExecInfo.lpParameters = "C:\\test\\mydoc.doc";
shExecInfo.lpDirectory = NULL;
shExecInfo.nShow = SW_MAXIMIZE;
shExecInfo.hInstApp = NULL;
ShellExecuteEx(&shExecInfo);

Please let me know what wrong with this code.

Thanks

SNI

Re: Problem in ShellExecuteEx.

Code-o-mat20-Jan-09 1:08

Re: Problem in ShellExecuteEx.

20-Jan-09 1:08

Does it work if you simply run outlook with a doc parameter from a console or using RUN in start menu? Maybe you need to specify other parameters to let Outlook know what you want it to do with that doc.

> The problem with computers is that they do what you tell them to do and not what you want them to do. <

SNI20-Jan-09 1:26

SNI

20-Jan-09 1:26

Thanks for reply. But I tried with other parameters but it is failing and giving following msg
"The command line argument is not valid. Verify the switch you are using." Is there any switch needs to be provided while specifying the file name.

SNI

Re: Problem in ShellExecuteEx.

Code-o-mat20-Jan-09 2:02

20-Jan-09 2:02

Check out here[^], it says, the command line argument for attaching a file is /a <path to file>

> The problem with computers is that they do what you tell them to do and not what you want them to do. <

Custom cursor with Win32

Steve_20-Jan-09 0:59

Steve_

20-Jan-09 0:59

Hi,

I would like to make it so that when the cursor is over my window it has a custom look. How can I achieve this with win32?

Thanks,

Steve

Code-o-mat20-Jan-09 1:11

20-Jan-09 1:11

One way is to handle the WM_SETCURSOR[^] message. A different way would be to specify your own cursor handle when registering a window class.[^].

> The problem with computers is that they do what you tell them to do and not what you want them to do. <

Nibu babu thomas20-Jan-09 1:14

Nibu babu thomas

20-Jan-09 1:14

wibblewoo wrote:
I would like to make it so that when the cursor is over my window it has a custom look. How can I achieve this with win32?

Using cursors![^]

Nibu babu thomas
Microsoft MVP for VC++

Code must be written to be read, not by the compiler, but by another human being.

Programming Blog: http://nibuthomas.wordpress.com

Steve_20-Jan-09 1:31

Steve_

20-Jan-09 1:31

Oh God I don't know how I didn't find that when I was looking.

Thanks.

Maximum value of MTU size

Nibu babu thomas20-Jan-09 1:53

Nibu babu thomas

20-Jan-09 1:53

wibblewoo wrote:
Oh God I don't know how I didn't find that when I was looking.

MSDN has an interesting set of "Using xxxx" series. If interested type in "Using" into the index edit box and you'll see a bunch of articles.

Nibu babu thomas
Microsoft MVP for VC++

Code must be written to be read, not by the compiler, but by another human being.

Programming Blog: http://nibuthomas.wordpress.com

Vishal Kumar Soni19-Jan-09 23:46

19-Jan-09 23:46

As per google, MTU(Maximum transmission unit) can have maximum value of 1500 bytes but I am sending more then 1500 bytes data over socket from one application to other(on differnet m/c).It is going fine. I have tried up to 3500 bytes.
Please tell that what is the maximum size of MTU and how can I find out?

Thanks in advance.

Regards,
Vishal Soni

Maximilien20-Jan-09 0:46

Maximilien

20-Jan-09 0:46

what's MTU ?

This signature was proudly tested on animals.

Vishal Kumar Soni20-Jan-09 0:50

20-Jan-09 0:50

Maximum transmission unit

Code-o-mat20-Jan-09 2:15

20-Jan-09 2:15

The MTU effects only packet size. You can use send specifying bigger buffers as the MTU, but -i belive it's TCP's job- TCP will cut your data into ~MTU sized packets, send that over, and the receiver side will put the fragments together to "recreate" your data. Or am i missing the point here?

> The problem with computers is that they do what you tell them to do and not what you want them to do. <

Vishal Kumar Soni20-Jan-09 2:41

20-Jan-09 2:41

I am trying to send 3500 byts.On the receiver side,I have not implemented the code to take care of fragmented packets.So both client and server application have not functionality to deal with fragmented packets.
Without this,I am able to send and receive more then 1500bytes but as per MTU,it should not get more then 1500 bytes.
So there is lot of confustion related to MTU? In which case it is linked to TCP/IP send/receive size.

Thanks and Regards,
Vishal Soni

CPallini20-Jan-09 3:05

CPallini

20-Jan-09 3:05

Vishal Kumar Soni wrote:
So both client and server application have not functionality to deal with fragmented packets.

That's fine, since TCP/IP does it for you.

Vishal Kumar Soni wrote:
Without this,I am able to send and receive more then 1500bytes but as per MTU,it should not get more then 1500 bytes.
So there is lot of confustion related to MTU? In which case it is linked to TCP/IP send/receive size.

Possibly packet fragmentation is an internal detail, hidden to the application layer.
Smile | :)

If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.

This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke

[My articles]

Stuart Dootson20-Jan-09 3:10

Stuart Dootson

20-Jan-09 3:10

Vishal Kumar Soni wrote:
So both client and server application have not functionality to deal with fragmented packets.

Your code doesn't, but the code **you call** does. I bet your code doesn't perform checksums on the data you send either - doesn't mean that doesn't happen (the ethernet layer will do that). I bet your code doesn't work out which computers your data should go through to get between client and server either - again, that doesn't mean that it doesn't happen.

Vishal Kumar Soni wrote:
So there is lot of confustion related to MTU?

Not really. Look at Wikipedia's page on MTU[^] - it quite clearly says that the MTU is the maximum size of data packet that can be transmitted by a layer of a communication protocol. Looking at the table of MTUs on that page, you can see that the MTU size depends on the transport you're using. Imagine you have this link to your server:

Client <-- <small>Wireless (802.11)</small> --> Gateway <-- <small>Ethernet</small> --> Gateway <-- <small>FDDI</small> --> Server

There are three different transports with three different MTUs (802.11=2272 bytes, Ethernet = ~1500, FDDI = 4500). Without an underlying layer that automatically adjusts for those different MTUs, your code would have to handle it all.

As ever with networking questions, I would recommend you download and become familiar with the IBM Networking Redbook[^].

Code-o-mat20-Jan-09 3:14

20-Jan-09 3:14

As ^CPallini said, you don't need to fiddle with fragmentation. You just need to Send and Recv, fragmentation is done by the TCP/IP layer, also it ensures you that you get your data in the same order you sent it, so don't worry about "puttinng your fragments together in the right order" on any side.

> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Life: great graphics, but the gameplay sux. <

Vishal Kumar Soni20-Jan-09 6:00

20-Jan-09 6:00

Thanks for reply.
This problem started from live system at customer side.Sender application is sending 1800 bytes on socket but reciever side is receiving only 1460 bytes.Then one of my senior colleague asked me that it MTU problem so we need to change our implemataion.

Randor 20-Jan-09 7:09

Randor

20-Jan-09 7:09

Vishal Kumar Soni wrote:
Then one of my senior colleague asked me that it MTU problem so we need to change our implemataion

Hi Vishal,

I have read the other responses and mostly agree with them for 99.9% of engineers. However there are valid reasons why some network engineers choose to enable a Large MTU Network[^]. By reducing SYN/ACK cross-talk you can significantly reduces network overhead and consequently increase network throughput. There are essentially two ways to improve TCP performance... one is by increasing the MTU and the other is enabling RFC-1323[^] known as the TCP window scale option.[^]

The answer to your question is that the MTU is generally "Auto-Discovered[^]" by default. You can disable this option and enforce a specific maximum transmission packet-size, however... if there is ONE router which cannot handle the oversized packet, it will send back an ICMP error message and cause the packet to resent in smaller chunks... this is known as packet fragmentation and is very harmful for throughput.

Best Wishes,
-David Delaune

Vishal Kumar Soni20-Jan-09 8:17