|
oh,my God!
I want get it from C/MFC code !!!
could you tell me ???
|
|
|
|
|
|
 You've made my day...
Nibu thomas
Software Developer
|
|
|
|
|
See here.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"We will be known forever by the tracks we leave." - Native American Proverb
|
|
|
|
|
I have created the file open/save dialog box using CFile dialog.
I selected the lengthy file path which is more than 512 bytes ( Jsapanese file path)
the return value from the doModal() is IDOK.
if I try to get the file name using the GetPathName(), it returns invalid truncated string.
Please let me know any way to get whether the file path returned is truncated or how to get the correct full path.
even the GetLastError() function return zero at tthis scenario.
Thanks in advance
sandeep
|
|
|
|
|
What is the size fo the buffer that you passed?
There is a member variable in the CFileDialog class called m_ofn which is an OPENFILENAME structure.
Get hold of the lpstrFile and pass a TCHAR buffer that is enough to hold the file name.
Nibu thomas
Software Developer
|
|
|
|
|
Yes I tried that by passing the maximum buffer, but still it return only truncated string. I looked into the implementation of the GetPathName() function and came to know that, it is returning only MAX_PATH. Current selected path is beyond the MAX_PATH. 
|
|
|
|
|
An update to my analyses is, it can return the file path upto 260 characters ( not bytes). If the selected path is beyond the 260 characters, it truncates.
This scenario is possible when the folder path it self will be almost equal to 260 characters. Now if we select that folder from save as dialog to save some file, it truncates the path.
Please le mt know whether I can change this to return me the full path.
Thanks in advance
Sandeep
|
|
|
|
|
UNICODE chars are two bytes long.
So make sure you supply the required buffer for this purpose. If you are using MAX_PATH then use (MAX_PATH*2).
Nibu thomas
Software Developer
|
|
|
|
|
Hello,
I'm trying to learn about overriding operators, so i wrote a simple class, Overrider, which allocates a small instance variable (an array) in its constructor. The problem is with the + operator; if I allocate the return object on the stack, it calls the destructor at the return statement, so for the statement
Overrider a, b, c;
...
a = b + c;
the object returned by (b + c) from operator + is not valid when it gets to to the operator = for a. When I trace the call stack, the destructor is called, and the instance-variable array is deleted, before it can be copied in the = operator.
If I allocate the object on the heap, the object returned from operator + is valid in the = operator, but then there's a memory leak.
I'm clearly missing something simple; I can post the code if that'd help, or if someone has a pointer to a tutorial that shows an example of overriding + when the class allocates memory in the constructor, I'd be appreciative.
thanks,
ed
|
|
|
|
|
|
Here's the code for operator +:
Overloader
Overloader::operator+ (
const Overloader& addend) const
{
Overloader result;
long v;
short* resultVoxels;
short* addendVoxels;
if (!result.Allocate()) {
return result;
}
for (v = 0; v < iNShorts; ++v) {
result.mArray[v] = mArray[v] + addend.mArray[v];
}
return result;
}
I think I've found the problem: I didn't have a copy constructor. I just implemented
one, performing a "deep" copy of the mArray instance variable, and now it seems
to work....
Thanks for any advice,
ed
|
|
|
|
|
Hi,
I have no idea about certificates but a problem:
I have three things:
- a file *.pem ---> !-----BEGIN PUBLIC KEY-----
-----END PUBLIC KEY-----<br />
- a signed base64 string<br />
- an unsigned base64 string<br />
<br />
the signed base64 string must be verify and compare with the unsigned string.<br />
<br />
but how???
|
|
|
|
|
GetPeerName will work only for TCP ?  in Multicast, for example, I'm trying many to one. so One Client keep listening to many servers. now I want to send back an ACK to the servers. how do I do? a sendto() can help? how? (Its all UDP)
NULL
|
|
|
|
|
Meat Loaf wrote: GetPeerName will work only for TCP ?
Correct. UDP is a connectionless protocol so there is no notion of a peer. There is a sender and a receiver; once the data is transferred, there is no connection between the two.
recvfrom() will tell you the address of the sender, so you can use that address for sending back the ACK. Be aware that the ACK may not actually arrive - UDP does not guarantee delivery.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
I have only a modicum of basic knowledge about programming in VC++6. Most of the time I am cold so I program to raise my body temperature by the unadulterated frustration C++ affords. However, this frustration is offset by the learning experience.
I’ve written a newsgroup client that downloads headers and articles from up to 10 newsgroups and deletes duplicates. My socket connection is derived from CAsyncSocket. It seems to run OK but since I have time, I was wondering if modifying the code by adding multi-threading would improve download performance. (I don’t even know if that is possible.) My newsgroup server allows 2 connections per host. I connect via a cable modem, only one PC is involved, and no router. My thought was that I might see only a marginal improvement since some delays, for example within the server, would still exist.
Regards
|
|
|
|
|
> if modifying the code by adding multi-threading would improve download performance
My short answer is: No. CAsyncSocket was designed to handle multiple sockets in one thread context (if you can have 2 connections to the server it's possible to create two socket instances in your application and split up download tasks among them). You could try a completely different socket architecture (with something else than CAsyncSocket), I don't see the need in your example.
/M
|
|
|
|
|
Thanks Moak. I've come to the same conclusion.
Others have suggested that a mult-thread app might include 1 for the connection and another for fuctions that could be done in parallel such as sorting, filtering and displaying. This also does not help much since there are not a lot of intensive other tasks to do. I use XHDR commands which is fast and download the article bodies afterwards for those articles I'm interested in.
Regards
|
|
|
|
|
I search to know using IVIDisplayX Control.Do I have to add control in the document class of my MDI application?
|
|
|
|
|
Hi, i have a property sheet which is tabbed and the tabs are stacked
there are 6 tabs which strech across two lines,
however when the property sheet is first called, the lower line of tabs seem to be
hidden, they only appear when i have clicked onto another tab
i have posted an image of what i mean, as its hard to explain [^]
Pages are added like
BOOL CTabSettings::OnInitDialog()
{
CDialog::OnInitDialog();
m_sheet.AddPage(&m_page0);
m_sheet.AddPage(&m_page1);
m_sheet.AddPage(&m_page2);
m_sheet.AddPage(&m_page3);
m_sheet.AddPage(&m_page4);
m_sheet.AddPage(&m_page5);
m_sheet.AddPage(&m_page6);
m_sheet.Create(this, WS_CHILD | WS_VISIBLE , 0);
m_sheet.ModifyStyleEx (0, WS_EX_TRANSPARENT);
m_sheet.ModifyStyle( 0, WS_TABSTOP );
int i,iNum=m_sheet.GetPageCount();
for(i=0;i
|
|
|
|
|
si_69 wrote: for(i=0;i {
m_sheet.SetActivePage(i);
}
What's this for?
It appears that you have a dialog containing a property sheet which has six property pages. Correct? Why not remove the dialog from the equation? Even though CPropertySheet is not derived from CDialog, managing a CPropertySheet object is similar to managing a CDialog object.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"We will be known forever by the tracks we leave." - Native American Proverb
|
|
|
|
|
DavidCrow wrote: for(i=0;i {
m_sheet.SetActivePage(i);
}
What's this for?
Someone recommending activating all property pages might solve the issue,
[^]
so it was worth a try
|
|
|
|
|
Your link does not go anywhere. Try again.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"We will be known forever by the tracks we leave." - Native American Proverb
|
|
|
|
|
DavidCrow wrote: Your link does not go anywhere. Try again
oops [^] try this one
|
|
|
|
|
I'm not sure why that suggestion would have been offered. It makes no sense.
"Let us be thankful for the fools. But for them the rest of us could not succeed." - Mark Twain
"We will be known forever by the tracks we leave." - Native American Proverb
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
