|
Hello,
I've started moving a MFC MDI application from VS2005 to VS2010 (used the samples Visual C++ 2008 Feature Pack as source) and got some problems with the menu now using CMFCMenuBar.
Normally all the menu items are customizable by the user, but I want to protect the main menu items File, Edit, View, Help, ... from user customizing and only allow the user to add his own main menu(s) to the menu bar.
I thought using CMFCToolBarButton::SetProtectedCommands but that doesn't help for the main items, for the sub menu items this works.
I found also out that I could add the 0 with the call lstProtectedCmds.AddTail( (UINT)0 ); to the protected commends but this prevents the menu bar completely from customizing and the user isn't able to add his own menu to the bar any more.
Any help or ideas are welcome.
Thanks,
Andreas.
|
|
|
|
|
Hi All,
How to reyurn char* in c++? My code is
extern "C" char* callFunction()
{
std::string stroutput = pObject->ProcessNumber("hi","hi");
char* strout = new char [stroutput.size()+1];
strcpy (strout, stroutput.c_str());
return strout;
delete[] strout;
}
Thanks in advance...
G.Paulraj
|
|
|
|
|
What you've done is almost correct.
2 things are not right.
First, you cannot use extern "C" if you're using std::string because string is an object of the basic_string class.
class is not understood by C.
Second, you cannot delete the memory inside the function.
Deletion has to be done by the caller.
Also there is no point in having any statements after the return statement.
|
|
|
|
|
«_Superman_» wrote: First, you cannot use extern "C" if you're using std::string
The extern "C" merely prevents name decoration of exported function or variable names, it has nothing to do with the underlying C++ code, which may use any classes internally.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
You're right. My mistake.
|
|
|
|
|
«_Superman_» wrote: My mistake.
The first I've seen from you; you must be having a bad day!
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
The worst. !!!EVER!!!
Need to cool off . Going to the bar.
|
|
|
|
|
The delete[] will never execute, because you are return ing before you get to it.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Richard and Superman,
Thanks for your reply.
Actaully i supposed to return std::string.
The thing is, this is a dll. and i am calling this dll from c# application.
If i return like
return "some value";
this is working fine. but if i return like,
char* str; or std::string str;
return str;
the output is not coming correctly.
from c# i am calling like
String str = somefunctionname();
How can solve this issue?
G.Paulraj
|
|
|
|
|
Since you're doing interop, you should return a BSTR .
So you will need to use the SysAllocString API on the string to convert it to BSTR .
|
|
|
|
|
First of all, if your function is part of a DLL called from outside that DLL, then memory allocated inside your function may not be released by the caller!
The reason is that the caller may not use the same memory mapping and therefore cannot manipulate the heap form your DLL.
There are various ways around that:
1. the easiest is to provide a release function in addition to your original one. The only pupose of that function is to release the buffer you previously allocated, and the caller of your function should call it once it doesn't need your string anymore.
2. A somewhat better solution, and in fact widely used, is to add another parameter to your function: a string buffer that the caller must pass to your DLL, so cou can copy the resulting string into it. Of course you must verify the buffer is big enough or else issue an appropriate error or warning. You couls also provide an additional function that simply returns the size you require the buffer to be, so the caller could first call this function, then allocate the memory and pass the resulting buffer to your function.
3. There are other ways, such as using Shared memory, but I think that would be overkill.
Here's a suggestion based on variant 2 above:
extern "C" std::size_t requiredSize();
extern "C" std::size_t getString(char* buffer);
char mystring[] = "hello world"; std::size_t requiredSize() {
return sizeof(mystring) / sizeof(char); }
std::size_t getString(char* buffer) {
if (!buffer) return 0; strcpy(buffer, mystring); return requiredSize(); }
And here's how to use it from C++:
#include "yourfile.h"
void foo() {
std::size_t sz = requiredSize(); char* mybuffer = new char[sz]; getString(buffer); puts(buffer); delete [] buffer; }
|
|
|
|
|
#include <stdio.h >
char *return_Char_Pointer(char *ptrChar)
{
ptrChar = "hello hi! I am returning a return char pointer (char *p)\n\n";
return ptrChar;
}
int main(int argc, char* argv[])
{
char *ptrChar = new char[255];
char *ptrChar1;
ptrChar1 =return_Char_Pointer(ptrChar);
printf("%s",ptrChar1);
delete []ptrChar;
return 0;
}
|
|
|
|
|
Are you posting bad code to set the enemy on the wrong track?
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]
|
|
|
|
|
You'd better use memcpy to copy the literal string to ptrChar. Doing it like the makes you call delete on statically allocated memory.
The assignment just returns the address of the literal string
Cheers, AT
Cogito ergo sum
|
|
|
|
|
I am surprised this will compile given the 'delete' is unreachable.
Anyway, just remove the delete and return strout to the caller. It is then the callers responsibility to free the memory.
==============================
Nothing to say.
|
|
|
|
|
Good one; make sure that you set the comiler warnings to max (4) and warnings as errors. That will at least make sure that something like this won't even compile.
Cheers AT
Cogito ergo sum
|
|
|
|
|
The problem with that is:
1. The caller may not know what method was used to allocate the memory (e. g. malloc or new), or if it was allocated at all, or instead just points to a static buffer! (Of course you could put that kind of information into the function documentation)
2. The OP put this function into a library interface. If bound statically, that would not pose a problem, but if bound dynamically, as a DLL, this DLL may use a separate heap - that means the caller may not even be able to release that memory. At least that's my understanding of DLLs.
|
|
|
|
|
Stefan_Lang wrote: The caller may not know what method was used to allocate the memory (e. g.
malloc or new), or if it was allocated at all, or instead just points to a
static buffer!
Thats what documentation is for. This is actually quite common procedure, many APIs do this.
Stefan_Lang wrote: The OP put this function into a library interface
Then the dll can expose a func that the caller can call to do the delete.
==============================
Nothing to say.
|
|
|
|
|
hi guys where am i going wrong?? bear in mind this is just part of the prog.
#include <stdlib.h>
# include <string.h>
#include <stdio.h>
#include <iostream>
use namespace std ;
static FILE *stream;
static char buffer[80];
abnormal_end()
{
fclose(stream);
printf("Abnormal extraction termination.\n");
return (0);
}
int main()
{
char path[80];
FILE *stream;
char filestr[256];
|
|
|
|
|
Where are you going wrong? ...Do you want us to guess at what your problem is?
|
|
|
|
|
my apologies ..i am a complete novice to c++. i have decided to write the extraction program in parts . the part i posted is an attempt to write the file reader....hope it makes sense
#include <stdlib.h>
# include <string.h>
#include <stdio.h>
#include <iostream>
use namespace std ;
static FILE *stream;
static char buffer[80];
abnormal_end()
{
fclose(stream);
printf("Abnormal extraction termination.\n");
return (0);
}
int main()
{
char path[80];
FILE *stream;
char filestr[256];
|
|
|
|
|
You still didn't state your problem...
[Note: I didn't downvote, but if you keep posting code with no clear problem statement, expect more downvotes.]
|
|
|
|
|
[Note: I did 1 vote]
You have showed precisely 3/5ths & 5/8ths of nothing new in this post. There IS NOT enough information for any kind of useful (in the sense of this particular problem) response.
Problems with your posts include (though are not limited to):
1) Failure to use code tags (this time)
2) Repetition of the same useless snippet of code (this time)
3) A failure to actually state what the problem is (both times)
4) The changing to a different username for the repost (this time)
5) Nothing you've showed has anything to do with the DXF format, even if this is the type of file you're trying to process, there is nothing related to DXFs in any way. (both times)
You do realize that we've got no idea of what you're trying to do, save for the mention of DXFs in the subject line? You've not showed any code that can fail, with the possible exception of the fclose - though you don't check the return value, nor will an attempt to close an invalid file result in a crash.
(Assuming your primary language is indeed english) This is an example of sloppiness and lazy questioning at close to its peak.
Wait a minute - even if it's not, you still (presumably) have access to the same Google Translate pages that we do. Even if the grammar may become a little battered in the process of automatic translation, there is still no actual information in your posts.
I'd be happy to change that 1 back into something a little more pleasant, should you have the urge to edit the last post such that it resembles a serious question.
But if that doesn't happen, it's remains merely 'noise'.
|
|
|
|
|
I can't believe you took the time to write all that...
[I accidentally bookmarked your post last night, fat fingers+small mobile screen= pushing wrong links].
|
|
|
|
|
Correct me if I'm wrong, but I am guessing that what you are saying here is that you have have no idea how to write the rest of the program and you think CP members are going to do it for you.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|