|
you need to build your EXE with "static linking"
|
|
|
|
|
Thanks a lot Chris ... it solved my problem 
but now i am just wondering if just statically linking is all what is needed to run it on other PCs
what is the role of redistributable "vcredist.exe" ! 
|
|
|
|
|
You can ship all the DLLs that *you* have written. For MFC DLLs, you can distribute the latest version of vcredist.exe[^] along with your application.
Nobody can give you wiser advice than yourself. - Cicero
.·´¯`·->Rajesh<-·´¯`·.
Codeproject.com: Visual C++ MVP
|
|
|
|
|
well just statically linking the DLL while building solved my prob.
but i think shipping all the dlls is not a good idea ... coz it asks for a single Dlls and gives error ... if provide that .. it asks for another ... (i dont know how many will there be)and i had to search it in the installed VS components for it .... also i guess most of them are not freely redistributable under MS VS Lisence
|
|
|
|
|
hi
I implimented CustomDraw
when i put lptvcd->clrTextBk = CLR_NONE ;
lables are painted with black color background but not trasparent
please some one tell me what shud i change in the code to get the CtreeCtrl lables trasparent
void CLeftPaneTreeCtrl::OnCustomDraw(NMHDR* pNMHDR, LRESULT* pResult)
{
switch(pNMHDR->code)
{
case NM_CUSTOMDRAW:
{
LPNMTVCUSTOMDRAW lptvcd = (LPNMTVCUSTOMDRAW )pNMHDR;
lptvcd->clrTextBk = CLR_NONE ;
lptvcd->clrText = (RGB(0,0,255));
//SetTextColor(RGB(255, 0, 0));
//SetBkMode(lplvcd->nmcd.hdc,TRANSPARENT);
switch (lplvcd->nmcd.dwDrawStage)
{
case CDDS_PREPAINT:
// Need to process this case and set pResult to
// CDRF_NOTIFYITEMDRAW, otherwise parent will never receive
//CDDS_ITEMPREPAINT notification. (GGH)
*pResult = CDRF_NOTIFYITEMDRAW;
return;
}
}
}
}
|
|
|
|
|
What happens if
// lptvcd->clrTextBk = CLR_NONE ;
dont get to work?
Greetings from Germany
|
|
|
|
|
Hi
Karstenk Thanx for the reply
if i coment out that line it will paint white background
but i painted gradient color on CTreeCtrl backgoud so it doest help me
and one more thing
lplvcd->clrTextBk = CLR_NONE ; works fine with CListCtrl lables
but same thing doesnt work for CTreeCtrl lables
and any other color other than trasparent will take effect properly
-SetBkMode(hdc,TRASPARENT) also wont work - it doesnt take any effect
|
|
|
|
|
You're gonna have to draw the labels yourself.
But who is the king of all of these folks?
|
|
|
|
|
how to do that can u please give me some pointers
how to start drawing the lables and where
in customdraw?
|
|
|
|
|
|
Hi,
I was wondering if you could give me an example of when you would want to store objects in a list and when would you want to store them in a multi set.
The multi set of course having the ability to store multiple values of the same object.
Thanks
|
|
|
|
|
You could use a multi set to store the factors of a prime number, say, 120: {2, 2, 2, 3, 5}
Using a list this would be {2,3,5} if you just wanted to identify the factors themselves.
Using the multi set, you could recontruct the prime (by multiplication of the contents of the multi set). The list would just give you the factors.
|
|
|
|
|
Hey thanks for your input. I thought Lists can store duplicates ? So it could store {2,2,2,3,5} ?
|
|
|
|
|
I think the difference is that multiple identical elements in a multi set can serve as their own sort keys, so the keys are not unique.
|
|
|
|
|
List gives you fast insertion (O(1)), potentially slow lookup (O(n)). Multiset gives you sorted insertion, and reasonably fast lookup (both O(log n)).
But who is the king of all of these folks?
|
|
|
|
|
#include <time.h>
#include<stdio.h>
#include <conio.h>
#include <stdlib.h>
#include <Windows.h>
void main()
{
time_t curr, bir;
struct tm *curr_tm, *bir_tm;
curr = time(NULL);
bir = time(NULL);
curr_tm = localtime(&curr);
bir_tm = localtime(&bir);
// printf("%s\n", asctime(curr_tm));
// printf("%s\n", asctime(bir_tm));
bir_tm->tm_year = 83;
bir_tm->tm_mon = 11;
bir_tm->tm_mday = 26;
printf("%s\n", asctime(curr_tm));
printf("%s\n", asctime(bir_tm));
}//main
i don't know why
printf("%s\n", asctime(curr_tm));
printf("%s\n", asctime(bir_tm));
's result is same~
definitly curr_tm, bir_tm 's paramata is different~
example)
curr_tm = localtime(&curr);
bir_tm = localtime(&bir);
firstly, i am sorry, i am from korea.
and i am not good in wriitting english so please understand~
Thank you everyone~
|
|
|
|
|
curr_tm = localtime(&curr);
bir_tm = localtime(&bir);
from the MSDN[^]:
gmtime, mktime, and localtime all use a single statically allocated tm structure for the conversion. Each call to one of these routines destroys the result of the previous call.
in other words, curr_tm and bir_tm have the same value because they are pointing at the same structure, because localtime returns the same structure each time you call it.
|
|
|
|
|
Chris Losinger wrote: gmtime, mktime, and localtime all use a single statically allocated tm structure for the conversion. Each call to one of these routines destroys the result of the previous call.
Though the assertion are in fact related, in the OP particular case, IMHO the
Chris Losinger wrote: use a single statically allocated tm structure
is more relevant than
Chris Losinger wrote: Each call to one of these routines destroys the result of the previous call
.
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.
[my articles]
|
|
|
|
|
From localtime documentation [^]
gmtime, mktime, and localtime all use a single statically allocated tm structure for the conversion. Each call to one of these routines destroys the result of the previous call.
hence both curr_tm and bir_tm point to the same static struct.
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.
[my articles]
|
|
|
|
|
I have the following class member function:
void CTreeGraft::DetermineOverlay(OptionType WhichOption) {
double Temp1;
double Temp2;
Temp1 = 0.0;
Temp2 = 0.0;
for(int col = 0; col < 2; col++) {
int Limit = static_cast<int>(Graft[col].size()) - 1;
for(int row = 1; row < Limit; row++) {
Temp1 = Graft[col+1][row+1]->GetUnderlyingPrice();
Temp2 = Graft[col+1][row+3]->GetUnderlyingPrice();
switch(WhichOption){
case 0:
if (m_dStrike < Temp1 && m_dStrike > Temp2) {
FineMesh[col].push_back(Graft[col][row]);
}
break;
case 1:
if (m_dStrike > Temp1 && m_dStrike < Temp2) {
FineMesh[col].push_back(Graft[col][row]);
}
break;
}
}
}
}
I instantiate a new member of the class and call this function. The app bombs. On debugging, the VS 2005 debugger is telling me that variable Temp1 "needs a stack frame" and variable Temp2 cannot be found. Furthermore, when it gets to the for loop, the index variables don't initialize properly at all. Is there something obvious I'm missing here? It's very strange behaviour...
Oh man am I tired. I glanced up and noticed the Solution Configuration was set to "release" instead of "debug".  
modified on Thursday, January 31, 2008 8:19:54 AM
|
|
|
|
|
73Zeppelin wrote: The app bombs.
73Zeppelin wrote: int Limit = static_cast<int>(Graft[col].size()) - 1;
for(int row = 1; row < Limit; row++) {
Temp1 = Graft[col+1][row+1]->GetUnderlyingPrice();
Hint: the above three lines give the error definition.
Temp2 = Graft[col+1][row+3]->GetUnderlyingPrice();
row+1 is bad, row+3 is evil.
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.
[my articles]
|
|
|
|
|
CPallini wrote: Hint: the above three lines give the error definition.
Temp2 = Graft[col+1][row+3]->GetUnderlyingPrice();
row+1 is bad, row+3 is evil.
Actually, I guarantee the row length in another function so row+3 is always okay.
I found the problem - I had the build configured to "release" instead of "debug".
|
|
|
|
|
73Zeppelin wrote: Actually, I guarantee the row length in another function so row+3 is always okay.
Well, of course you're right. But don't blame me if I don't like such (IMHO, at least) misleading code.
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.
[my articles]
|
|
|
|
|
CPallini wrote: Well, of course you're right. But don't blame me if I don't like such (IMHO, at least) misleading code.
I know it's messy - that's the nature of the project. I have a coarse lattice structure (like a grid) and over the coarse structure I overlay a finer mesh (a grid with higher resolution). Each column of the grid varies in length and sometimes I have to compare rows of different columns that are several integers (i.e. 3) apart. It's a complicated calculation and I make alot of effort to ensure that I don't exceed array bounds.
It's someone else's algorithm, but I have to implement it - I have no choice. I have to compare this method to my own method (which is much, much simpler  ).
|
|
|
|
|
Pardon, I gave a second look at your code and noticed the col+1 that makes indeed a big difference, my bad  .
BTW Physics, I suppose.
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.
[my articles]
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
