|
In pure win32 code. I need to set VScrool Position at the Bottom of the EditBox.
SendMessage( hWnd ,WM_VSCROLL, SB_BOTTOM, 0 ); is not working for me.
|
|
|
|
|
MFC, STUDIO 2008, MDI-project
if J know the name of class then
how can to define the identifier
of dialog wndow on base that
was created this class?
|
|
|
|
|
CHIVOTIOV wrote: MFC, STUDIO 2008, MDI-project
if I know the name of class then how can to define the identifier of dialog window on base that was created this class?
If I get you correctly you are on the lookout for GetParent()
You need to google first, if you have "It's urgent please" mentioned in your question.
 _AnShUmAn_
|
|
|
|
|
Hello,
I am doing an application with an "exe" file and some "dll" that are called from the exe.
When I run the exe in Debug (or Debug64) mode and the dll are compiled in Debug (or Debug64) mode the application runs without any problem. But if I mix Debug with Release (or Debug64 with Release 64) the application does not run, and I get this error:
"Unhandled exception at 0x77d4dd50 in PruebaLinkado.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0012c160.."
The dll has "Multi-threaded DLL (/MD)" option
And the exe file has "Multi-threaded (/MT)" option.
Can anybody help me with this problem?
Thanks in advance
|
|
|
|
|
Why would you mix debug and release mode binaries? 
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
Just during debugging phase.
If I want to debug in the dll and the exe file is working I don't want to change the exe file each time.
|
|
|
|
|
I don't understand. My question was - why would you have the executable in release mode and the dll in debug mode?
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
For example,
I have a develope Team with 5 developers.
One exe that runs the dlls that each developer builds.
If a developer wants to check his work it is not necesary to complie the exe file in debug, he has just to compile his dll in debug mode and check it.
Regards
|
|
|
|
|
And how will you know what is happening in the executable if it is built with no debug information? For instance, if an assertion occurs in the executable (even while loading the DLL), you won't know it. You don't have to compile the executable every time. You say the executable remains the same, so, you can have it built with debug symbols in it. After your bugs are fixed, you can build binaries without debug information in it.
Somehow, the idea of mixing separate binaries, some with and some without debug information doesn't look strikingly impressive. 
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
A warm welcome to 'The Legend' [^].
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]
|
|
|
|
|
Ah, thanks. 
The link you provided doesn't work, BTW. I went to your profile to view the updated post.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
Rajesh R Subramanian wrote: The link you provided doesn't work, BTW. I went to your profile to view the updated post.
Yeah, it looks like the 'Permalink' mechanism is broken.
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]
|
|
|
|
|
So if you you make a macro in Excel, and in this macro you call to a function located in your dll, you are able to put Excel.exe in debug?
|
|
|
|
|
It would be of help to know the difference between Excel and your program: Excel doesn't throw a bad_alloc exception and crash to death. Your application does.
Which means that there's something wrong (you don't know if it's at the library side or at the consumer side), so I asked you to debug them together. You may drop my idea of using debugging symbols if you didn't like it.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
Yes, acctually that's my problem.
I have done a simple test:
Create a dll with a function. (for example:
__declspec(dllexport) int test1(const std::string& chain)<br />
{<br />
std::string test;<br />
<br />
test = "testing: ";<br />
test += chain;<br />
return 13;<br />
})
Create a exe that import the funtion. (for example:
#pragma comment(lib, "DllTest.lib")<br />
__declspec(dllimport) int test1(const std::string& cadena); )
Call to the function of the dll form the exe. (for example:
int io;<br />
std::string stTest;<br />
<br />
io = test1("testing testing");)
And the results are:
Both in debug -> works (so I cannot find information about the crash)
Both in release -> works
One in debug and one in release -> Crash to death
I think that the problem is in the project options, because there is nothing strange in the code.
|
|
|
|
|
Yes he can.
Be careful: don't challenge Rajesh... 
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]
|
|
|
|
|
Ok Ok.....
|
|
|
|
|
Epi wrote: "Unhandled exception at 0x77d4dd50 in PruebaLinkado.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0012c160.."
Every time a question with an error description like this it will be followed by another question: have you actually used your debugger?
On the other hand, mixing debug and release built EXE and DLLs will in many cases lead to exceptions that complain about dynamic memory allocations. This is due to that new is redefined in the debug version and adds some book keeping features in order to detect buffer overruns and such. It seems like this is your current problem.
Epi wrote: The dll has "Multi-threaded DLL (/MD)" option
And the exe file has "Multi-threaded (/MT)" option.
Shouldn't one of them be a debug version? 
You may also benefit from reading this excellent article[^].
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
I am using the debugger, and now I change the options of the executable to Multi-threaded Debug (/MTd) and I get the same.
For instance I am working with a little example.
In this example in the dll I have this funtion:
__declspec(dllexport) int test1(const std::string& chain)<br />
{<br />
std::string test;<br />
<br />
test = "testing: ";<br />
test += chain;<br />
return 13;<br />
}
and I am calling it from the exe.
I import it:
<br />
#pragma comment(lib, "DllTest.lib")<br />
__declspec(dllimport) int test1(const std::string& cadena);
and after I call it
int io;<br />
std::string stTest;<br />
io = test1("testing testing");
When I call the function test1, as you predict I get a bad ptr 0xcccccccc.... So should be in the size...
|
|
|
|
|
Epi wrote: I change the options of the executable to Multi-threaded Debug (/MTd) and I get the same.
Linking with the debug built version of a library you're using when you're building the debug version of your own binary seems like a Good Idea. 
Yes, you will get the same result, but now you're using the correct version of the runtime libraries if you happen to run into other problems.
Epi wrote: When I call the function test1, as you predict I get a bad ptr 0xcccccccc....
This suggests an uninitialized stack value.
Read more here[^].
I suspect this to origin from the mix up between debug and release versions and the fact the a debug built binary will add book keeping for both the stack and heap.
Stop mixing them and you'll probably get the result you want.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
I am about to fininsh the article Debug vs Release it is really interenting.
But I think it is not a code problem, because in the test that I have done just now, I haven't anything else except an executable that call a function in a dll passing it a string. No pointers, no arrays...
|
|
|
|
|
I guess it is due to a mismatch between the runtime library which is used for your exe and for your dll.
Epi wrote: I haven't anything else except an executable that call a function in a dll passing it a string. No pointers, no arrays...
No really correct: a std string allocates an array internally, and that's what causing the troubles. You are allocating it in your executable and trying to release it in your dll (or the other way around). As you are using two different runtime libraries, there's a crash when the destructor of the string is called because the dll and the exe do not use the same heap.
I'm not really an expert there but I encountered that problem before, I think you are facing the same problem.
|
|
|
|
|
Ok. Thank you,
Also is related the project option
Basic RunTime Check,
"Default" in all the configurations
Now it works,
Thank you very much to all of you
|
|
|
|
|
Hi, I am creating one sample application that uses SQL Server and create one table having ID and Title (Unicode data).My problem is that i am using unicode data and when i open the table, "Question mark " is displayed in Title instead of unicode data. My workspace is unicode compiled and i am using nvarchar for lingual data as a variable. Here is my code
CDatabase db;
CString strLingual = L"";
m_edt_lingual.GetWindowTextW(strLingual);
CString strQuery;
try
{
if (db.Open(NULL, FALSE, FALSE, _T("Driver={SQL Native Client};Server=SHILPI_PHADNIS\\SQLEXPRESS;Database=TransTool;Uid=sp;Pwd=np;")))
{
db.ExecuteSQL(_T("CREATE TABLE WDCheckLingual (ID INT, Title NVARCHAR(50))"));
for (int i = 0; i < 10; i++)
{
strQuery.Format(_T("INSERT INTO WDCheckLingual (ID, Title) VALUES (%d, '%s')"),
i + 1, strLingual);
db.ExecuteSQL(strQuery);
}
}
}
catch (CException *e)
{
e->ReportError();
e->Delete();
}
Thanks in advance....
Yes U Can ...If U Can ,Dream it , U can do it ...ICAN
|
|
|
|
|
Hello,
This is with regards to the query you asked me here[^]. Somehow, I am unable to add a reply there. So, I sent you an email. If you have not received, feel free to reply here and I shall assist you.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
