|
Both VC 6.0 and 7.1 allow you to change the mnemonic (the IDS_... value) within the string table editor, and VC 7.1 also allows you to change the number that it is mapped to within the editor. I think for VC 6.0 you need to change the number within the resource.h file if you want to change the mapper resource number.
Dave
http://www.cloudsofheaven.org
|
|
|
|
|
Thanks.
I guess I have to change it one by one.
Regards,
shin
|
|
|
|
|
|
Does anyone have any ideas / sample code on how to upload a file using wininet from a C++ client application to a java servlet for processing.
|
|
|
|
|
You need to do a HTTP POST of your data to the servlet. This MSDN page[^] on wininet should provide pointers on how to begin with posting.
|
|
|
|
|
That is exactly what I want to do. What I don't understand is how to make the file part of the request object. I think I need to create a handle to the local file, read it into a buffer, then use the InternetWriteFile function to write the buffer to the Http request object. Is that right? Do you know of any code samples that would make this process clearer?
|
|
|
|
|
Hi,
I have a problem which I don't fully understand... I have main View class which creates a non-modal Property sheet containing 2 property pages (this works as a tabbed property window). All this works fine.
However, I need to call some public member functions in the parent View class from within the Property Pages (eg when the user adjusts a setting in the tabbed property palette, the changes are reflected in the main view). The minute I add the include for the View class header in the Property Page class, I can't compile; I guess it creates some sort of infinite loop (the definition of the parent class tries to process the definition of the child window class which in turn includes a definition of the parent).
How do I get around this?
Any help would be greatly appreciated.
Simon
|
|
|
|
|
Try forward declaring the parent class in the child's header file. Something like this:
// CChildDlg.h
class CParentView;
class CChildDlg
{
...
CParentView* m_pView;
};
and then #include the parent's header in CChildDlg.cpp where you can actually use the pointer.
Please note, some professor teaching OO design will tell you that this is a sign of a design with a high amount of coupling and thus bad. But I'm not a professor teaching OO design, so I'm not going to tell you that.
|
|
|
|
|
Thanks very much for the advice.
I totally take on board the bad OO vibes...to be honest this had occurred to me. However, how is this problem usually overcome? It must be fundamental to most applications? Few don't have little tool palettes appearing all over the show. Am I missing some well-known design technique to avoid coupling?
|
|
|
|
|
Put the #include in the .cpp file, and then put
class MyViewClass;
in the header file for the property page.
And read the FAQ, I'm sure it mentions this stuff.
Christian
I have drunk the cool-aid and found it wan and bitter. - Chris Maunder
|
|
|
|
|
Humm..
Here's a common solution I use to solve these types of problems: take each .cpp file you have and see what includes they make. Include, afterall, does nothing else than slap the entire file specified to the position where the command is. This is the easy way to think it.
Following this logic, if you want to avoid including a header file, you can always use the extern keyword. This word, when placed in front of a type, specifies that this type is declared in some other object module. The linker is then responsible to finding this declaration, and if you have the view class header included in any other .cpp file taking part in the linking process, the declaration of the class will be found.
Hence, just put a 'extern class CMyDerivedView' and include a 'CMyDerivedView* pParent' to the property page class. Make sure that the .cpp file of CMyDerivedView is partaking the build when using this solution.
Note that when you have a pointer to your class, you can always access the parent CView class of your view class by using the GetParent method (assuming the property pages are children of the view). This way, you can access the CView master class. Doing a 'DYNAMIC_DOWNCAST' from this pointer to your derived view class is then possible.
This means that in the most extreme case, all that is required is to put a 'extern class CMyDerivedView' in the property page .cpp file, and then using this method to access the parent view. However, this variable will remain global and may cause further problems down the road.
-Antti Keskinen
----------------------------------------------
The definition of impossible is strictly dependant
on what we think is possible.
|
|
|
|
|
Thanks for the going to the trouble of writing that explanation Antti. The GetParent method was something I hadn't considered at all.
Thanks for time.
Simon
|
|
|
|
|
Dear All,
I compiled a project under Unix, I have got the following errors:
------------------------------------------
CC -I. -DUNIX -c XPCFileStat.C -g -o XPCFileStat.o
"XPCFileStat.C", line 11: Warning: String literal converted to char* in formal argument sMsg in call to XPCException::XPCException(char*).
"XPCFileStat.C", line 20: Warning: String literal converted to char* in formal argument sMsg in call to XPCException::XPCException(char*).
"XPCFileStat.C", line 28: Warning: String literal converted to char* in formal argument sMsg in call to XPCException::XPCException(char*).
"XPCFileStat.C", line 36: Warning: String literal converted to char* in formal argument sMsg in call to XPCException::XPCException(char*).
"XPCFileStat.C", line 48: Warning: String literal converted to char* in formal argument sMsg in call to XPCException::XPCException(char*).
"XPCFileStat.C", line 59: Warning: String literal converted to char* in formal argument sMsg in call to XPCException::XPCException(char*).
"XPCFileStat.C", line 70: Warning: String literal converted to char* in formal argument sMsg in call to XPCException::XPCException(char*).
"XPCFileStat.C", line 77: Error: The "&" operator can only be applied to a variable or other l-value.
"XPCFileStat.C", line 221: Warning: String literal converted to char* in formal argument sMsg in call to XPCException::XPCException(char*).
"XPCFileStat.C", line 228: Error: The "&" operator can only be applied to a variable or other l-value.
2 Error(s) and 8 Warning(s) detected.
*** Error code 2
make: Fatal error: Command failed for target `XPCFileStat.o'
------------------------------------------------------
Here is the main part of the program:
#include <xpcfilestat.h>
#include <iostream.h>
XPCFileStat::XPCFileStat()
{
long lMaxpath;
// Determine the maximum size of a pathname
if ((lMaxpath = pathconf("/", _PC_PATH_MAX)) == -1)
{
XPCException newExcept("Could not determine maximum pathname length"); // warning line 11
throw newExcept;
return;
}
// Allocate memory for the pathname
cFileName = new char[lMaxpath + 1];
if (!cFileName)
{
XPCException newExcept("Could not allocate memory for cFileName"); // warning line 20
throw newExcept;
return;
}
// Store the current working directory
if (getcwd(cFileName, lMaxpath) == NULL)
{
XPCException newExcept("Could not get current working directory"); // warning line 28
throw newExcept;
return;
}
// Retrieve the file's statistics
if (lstat(cFileName, &sStatBuf) == -1)
{
XPCException newExcept("Could not obtain statics on directory."); // warning line 36
throw newExcept;
return;
}
}
XPCFileStat::XPCFileStat(char *_psFileName)
{
// Allocate memory to store the pathname
cFileName = new char[strlen(_psFileName)+1];
if (!cFileName)
{
XPCException newExcept("Could not allocate memory for cFileName"); // warming line 48
throw newExcept;
return;
}
// Copy the pathname to the private data member
strcpy(cFileName, _psFileName);
// Retrieve the file's statistics
if (lstat(cFileName, &sStatBuf) == -1)
{
XPCException newExcept("Could not obtain statics on directory."); // warning line 59
throw newExcept;
return;
}
}
XPCFileStat::XPCFileStat(const XPCFileStat &_oldClass)
{
cFileName = new char[sizeof(_oldClass.cFileName)+1];
if (!cFileName)
{
XPCException newExcept("Could not allocate memory for cFileName");// warning line 70
throw newExcept;
return;
}
strcpy(cFileName, _oldClass.sGetFileName());
memcpy((void *)&sStatBuf, (void *)&_oldClass.getStatBuf(), sizeof(struct stat)); //here is first error
}
enum eDirectoryTypes XPCFileStat::iGetFileType()
{
// Extract the file type bits from st_mode and match them up with
// the file type constants
switch(sStatBuf.st_mode & S_IFMT)
{
..............................
}
}
enum ePermissions XPCFileStat::iGetOwnerPermissions()
{
// Extract the owner permission bits and return the appropriate
// permission value
switch(sStatBuf.st_mode & S_IRWXU)
{
.......................................................
}
}
enum ePermissions XPCFileStat::iGetGroupPermissions()
{
// Extract the group permission bits and return the appropriate
// permission value
switch(sStatBuf.st_mode & S_IRWXG)
{
..................................................
}
}
enum ePermissions XPCFileStat::iGetOtherPermissions()
{
// Extract the "other users" permission bits and return the appropriate
// permission value
switch(sStatBuf.st_mode & S_IRWXO)
{
......................................
}
}
XPCFileStat &XPCFileStat::operator=(const XPCFileStat &_oldClass)
{
if (this == &_oldClass)
return *this;
if (sizeof(cFileName) < sizeof(_oldClass.sGetFileName()))
{
delete [] cFileName;
cFileName = new char[sizeof(cFileName)];
if (!cFileName)
{
XPCException newExcept("Could not allocate memory for cFileName"); // warning line 221
throw newExcept;
return *this;
}
}
memcpy((void *)cFileName, (void *)_oldClass.sGetFileName(), sizeof(_oldClass.sGetFileName()));
memcpy((void *)&sStatBuf, (void *)&_oldClass.getStatBuf(), sizeof(struct stat)); // here is the 2 error
}
=======================================================================
I would be glag if someone would help me to solve at least those two errors. Your help will be appreciated!
Thank you in advance for your reply.
Regards,
Azzedine
|
|
|
|
|
Regarding the warnings, what is the prototype for XPCException's constructor?
For both the errors, omit the address-of operator (&) from the second parameter to memcpy().
One other item that looks problematic:
if (sizeof(cFileName) < sizeof(_oldClass.sGetFileName()))
{
delete [] cFileName;
...Since it appears that cFileName is a pointer, sizeof() will always return 4, as opposed to the actual amount allocated to that pointer. In the second use of sizeof(), I question the use of a function call as a parameter.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
I have 20 items in my List View and I update them rapidly (change text of subitem)
interval = 100millisecond (report type only)
They are very flicker
Is there a way to fix it ?
VC6,XP
thank a lot ~!
|
|
|
|
|
Have you looked at CWnd::SetRedraw()?
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
you can derive and write you own CView::OnUpdate() function... since CListView is derived from the CView Class.
this will allow you to redraw only part of the View. The default OnUpdate() is to redraw the entire client area.
This is exactly what you need to do to reduce flickering.
|
|
|
|
|
Two calls to CWnd::SetRedraw() takes far less code, however!
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
If you derive from CView you get more control over the drawing... you can set the icons and text descriptions to go with them. If you override the CWnd class then you cannot.
|
|
|
|
|
CListView is already derived from CView. More control over the drawing is not required, and I did not mention anything about "overriding the CWnd class", however you would do that.
I'm assuming the OP had something akin to the following for populating the listview:
for (int x = 0; ...)
{
listview.InsertItem(...);
}Simply changing it to the following will keep the control from flickering:
listview.SetRedraw(FALSE);
for (int x = 0; ...)
{
listview.InsertItem(...);
}
listview.SetRedraw(TRUE);
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
The flickering will still occur, since he is updating the client area every 100 milliseconds.
Thats why i said to override. If he uses the default setdraw, it will update and draw the whole client area, which will still flicker.
|
|
|
|
|
Hi guys
If I have a file in a web place http:\www.myweb.com\text\myfile.txt
Is there a simple way to do something similar to
fopen("http:\www.myweb.com\text\myfile.txt", "rt")
or it's impossible?
Best Regards
|
|
|
|
|
Although I've never tried, I believe sockets is what you'll need (e.g., recv(), send(), connect()). If, however, you are using MFC, take a look at CFtpConnection::OpenFile().
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Thanks I'll take a look
Dr.Pi
|
|
|
|
|
I don't think you can do that directly ...You can try CHttpFile class in MFC which will help you ...
Cause is my effort;
Effect is God's effort
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
