|
You are calling BeginPaint for every message (not just WM_PAINT), but you only call EndPaint after processing a WM_PAINT message. You need to move all code related the the painting into the block that handles the WM_PAINT message. You also need to select your brushes and pens into the device context before you draw anything. And lastly you need to delete any DC objects that you use in painting.
I would suggest studying the GDI documentation on MSDN for sample code. But be aware that GDI and GDI+ are being deprecated by Microsoft in favour of Direct2D API Reference (Windows)[^]
|
|
|
|
|
Hi all of you. I come here hoping to solve a problem that I have met on retrieving data from DB (SQL Server).
I retrieve data in the following way:
pRs->GetFieldValue(i, *pDBVariant);
nothing special ... (pRS is CRecordset*, and pDBVariant is CDBVariant*).
And this is method to format data:
CString CMyDoc::FormatData(CDBVariant* pDBVariant)
{
CString sRet;
do
{
if(NULL == pDBVariant)
break;
switch(pDBVariant->m_dwType)
{
case DBVT_LONG:
TRACE("DBVT_LONG\n");
sRet.Format(_T("%d"), pDBVariant->m_lVal);
break;
case DBVT_DOUBLE:
TRACE("DBVT_DOUBLE\n");
break;
case DBVT_SHORT:
TRACE("DBVT_SHORT\n");
break;
case DBVT_SINGLE:
TRACE("DBVT_SINGLE\n");
break;
case DBVT_STRING:
TRACE("DBVT_STRING\n");
break;
case DBVT_ASTRING:
TRACE("DBVT_ASTRING\n");
sRet = *pDBVariant->m_pstring;
break;
case DBVT_DATE:
TRACE("DBVT_DATE\n");
break;
case DBVT_WSTRING:
TRACE("DBVT_WSTRING\n");
CStringW wstring = *pDBVariant->m_pstringW;
sRet = CString(wstring);
break;
}
}
while(FALSE);
return sRet;
}
I have the following SQL:
SELECT nUser FROM my_table;
nUser has int SQL data type, and when I test this data with CMyDoc::FormatData, the returning data type are: DBVT_LONG
Ok, let take another SQL:
SELECT dVAT FROM my_table;
dVAT has decimal (10.2) SQL data type, and when I test this data with CMyDoc::FormatData, the returning data type are: DBVT_ASTRING ... why ?
I have tested another SQL:
SELECT sName FROM my_table;
sName has string SQL data type, and when I test this data with CMyDoc::FormatData, the returning data type are: DBVT_ASTRING, which are ok ...
but, excepting int SQL data type, all other SQL data type are having DBVT_ASTRING when I test this with CMyDoc::FormatData ... why ?
Can you help me ?
Thank you.
|
|
|
|
|
Have you checked the actual data returned in the variant to see whether it is a string or the value type you expect?
|
|
|
|
|
I re-written the FormatData method:
CString CMyDoc::FormatData(CDBVariant* pDBVariant)
{
CString sRet;
switch(pDBVariant->m_dwType)
{
case DBVT_LONG:
TRACE("DBVT_LONG\n");
sRet.Format(_T("%d"), pDBVariant->m_lVal);
break;
case DBVT_DOUBLE:
TRACE("DBVT_DOUBLE\n");
break;
case DBVT_SHORT:
TRACE("DBVT_SHORT\n");
break;
case DBVT_SINGLE:
TRACE("DBVT_SINGLE\n");
break;
case DBVT_STRING:
TRACE("DBVT_STRING\n");
break;
case DBVT_ASTRING:
TRACE("DBVT_ASTRING\n");
sRet = *pDBVariant->m_pstring;
break;
case DBVT_DATE:
TRACE("DBVT_DATE\n");
break;
case DBVT_WSTRING:
TRACE("DBVT_WSTRING\n");
CStringW wstring = *pDBVariant->m_pstringW;
sRet = CString(wstring);
break;
}
return sRet;
}
I have the following SQL:
SELECT nUser FROM my_table
In DB, nUser has "int" type. The result in FormatData method: DBVT_LONG
I have another SQL:
SELECT dValue FROM my_table
In DB, dValue has "decimal (10.2)" type. The result in FormatData method: DBVT_ASTRING !? Why ?
I have another SQL:
SELECT sName FROM my_table
In DB, dValue has "varchar(1024)" type. The result in FormatData method: DBVT_ASTRING - correct.
I noticed that any king of column type in DB, except "int" type, return DBVT_ASTRING in FormatData method ... why ?
I have tried to get data with CRecordset as dynaset, snaphot and dynamic ... every one of them had the same result ...
|
|
|
|
|
That is what you wrote in your original question, and removing the unnecessary do ... while() is not going to affect things. The issue is, what value type is SQL returning into your recordset? What you are looking at here is happening long after the data has been sent from the database.
|
|
|
|
|
What you have described sounds perfectly correct depending how you set the tables up.
Your nUser will be (look at SQL spec integer value between the range 2^ -31 and 2^31 -1) which is 32 bits or 4 bytes and would be a long in C/C++.
Your decimal (10.2) will be stored as an IEEE-754/-854-compliant bit string which will be 5-17 bytes.
If you stored your decimal(10.2) as singles/doubles you would get issues when you added them etc the small fractions you can't see would roll do you understand lets add 3 digits with 3 decimal places
Stored .... 10.2 format
-------------------------
1.344 .... 1.34
2.364 .... 2.36
1.134 .... 1.13
----------------------
4.842 .... 4.83
See the Problem 4.842 down to 2 digits is 4.84 and is not right answer they don't give same result and that is why SQL does not automatically covert numbers with precision.
I am sure if you make a table of doubles, single or floats they will come back as that just don't expect that from decimal, numeric which will be strings
In vino veritas
modified 25-Oct-17 15:22pm.
|
|
|
|
|
Yes, you are right ... I must change the data type in SQL in order to get right values in CDBVariant ... but I should ask this to my SQL colleagues ... 
Kindly thank you for your answer !!
|
|
|
|
|
It's unrelated to the problem but why the unnecessary do/while loop?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
Good point, it's unnecessary !
|
|
|
|
|
Hi,
Flaviu2 wrote: dVAT has decimal (10.2) SQL data type, and when I test this data with CMyDoc::FormatData, the returning data type are: DBVT_ASTRING ... why ?
Because the best way to pass a floating point value between network devices is as TEXT. The SQL server has no idea what architecture your device is using and how it will interpret the floating point value.
Best Wishes,
-David Delaune
|
|
|
|
|
|
#include <stdio.h>
int main()
{
int a=(1,2,3);
int b=(3,2,1);
for(; a>0; a--)
for(; b<3; b++);
printf("%d ", a*b);
return 0; }
output of this twister..??
|
|
|
|
|
|
|
The carpenter manufactures chairs and tables. He can sell them on the market, each table for Pt EUR and each chair for Pc EUR. He needs A hours and B wooden planks to produce one table and C hours and D planks for one chair. His weekly workload cannot be higher than H hours. His weekly supply for planks is S. The carpenter cannot store the planks. Help the carpenter to prepare his weekly schedule that maximizes his income. Design an algorithm that accepts A, B, C, D, H, S, Pt, Pc as an input and tells how many chairs and how many tables the carpenter should produce weekly, and what is the income assuming this production plan.
I haven't even got a clue... Can anyone please help?
|
|
|
|
|
We do not do your homework: it is set for a reason. It is there so that you think about what you have been told, and try to understand it. It is also there so that your tutor can identify areas where you are weak, and focus more attention on remedial action.
Try it yourself, you may find it is not as difficult as you think!
If you meet a specific problem, then please ask about that and we will do our best to help. But we aren't going to do it all for you!
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
of course It's just that I'm a total beginner and I just figured this might be the place to look for help. Well obviously I know it'd be best to start from inputing all the variables and then decide whether the chairs or tables are more profitable. My problem is I don't know how to decide that since there are two variables for each. Any suggestions?
|
|
|
|
|
Start by looking at how to would do it manually: get a pen and paper, and start playing with numbers.
Work out how you do it yourself, and an algorithm should become apparent.
Working this out is part of the task - heck, it is the task, you aren't supposed to implement it yet, if ever. It's an exercise in logical thinking and analysis, intended to start you thinking in "appropriate" ways. If you don't do it yourself, the "thought patterns" that you will use later don't start to form, and things can be a load harder later.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: Start by looking at how to would do it manually: get a pen and paper...
I wholeheartedly agree.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
Wel,
I agree with all the others. Every Computer Program starts with understanding the problem you are trying to resolve. This is quite fundamental! If you do not understand the problem, you will be unlikely to write a program that will resolve the issue at hand. the best start is possibly to write the question down, and in your mind break it down into the fundamental decisions program has to make. ( I have spent weeks with problems like this spinning through my head, trying to find the right approach to the problems I faced at the time)
Your question although wordy is quite basic. If you can resolve it, good and well, in that case Just consider yourself happy that you are (for now) not required to recover from "Fault" conditions.
If you can not, well, maybe you are not programmer material, and, you should possibly make another career choice.
Regards,
Bram van Kampen
|
|
|
|
|
|
Member 13478986 wrote: Can anyone please help?
Start with the chair only. So A, B and H. (Ignore S)
Figure that out.
Then add S.
After that add C and D. It might help to only do C, D, H and S first. However after you did it for A and B this should be trivial.
|
|
|
|
|
I have a heating control application that is based on some C++ code and some Arduino code. Having "woken up" to the 2038 timebomb, I am currently converting my code to cope with this (even though I shall in all probablity be "pushing up the daisies" by then !! ). As I believe Arduino uses 32 bit unsigned time variables, I believe it is OK after 2038 I am running MSVC 6.0 and, being of limited means, do not want to upgrade to 7.0 (or higher ) which I believe introduces a 64-bit version of the CTime class whicjh will cope with the situation. Having discovered an alternative solution ( Time64 - 64 bit Times for 32 bit Windows Apps[^] )I am doing this by abandoning CTime and replacing the code with 64-bit variables and using system calls. However, does anybody know if the MFC class CMonthCalCtrl is susceptible to the 2038 problem (as it DOES use CTime objects as parameters to it's functions) or am I 2038-safe by only employing calls using the SYSTEMTIME parameter ? I could test this but thought that I would ask the experts anyway!! Any help appreciated !
|
|
|
|
|
Member 13459733 wrote: I am running MSVC 6.0 and, being of limited means, do not want to upgrade to 7.0 (or higher ) which I believe introduces a 64-bit version of the CTime class...
Visual C++ .NET 2002 (a.k.a., MSVC++ 7) was strictly 32-bit.
Have you considered Visual Studio Community 2017? It's fee structure might be more accommodatable to you.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles
|
|
|
|
|
The MFC CMonthCalCtrl class is just a wrapper for the corresponding Windows system control. You might also have a look at the MFC sources (winctrl5.cpp) which are usually installed with Visual Studio. Then you will see that the class just sends messages using SYSTEMTIME parameters. The functions accepting CTime and COleDateTime parameters will convert those to SYSTEMTIME.
So you have to check the documentation for the used types:
Note
Windows does not support dates prior to 1601. See FILETIME for details.
The month-calendar control is based on the Gregorian calendar, which was introduced in 1753. It will not calculate dates that are consistent with the Julian calendar that was in use prior to 1753.
wYear
The year. The valid values for this member are 1601 through 30827.
COleDateTime uses the DATE Type | Microsoft Docs[^] internally.
For CTime see also the source (atltime.h). The oldest version I have here is VS 2003 (MSVC 7.1) which already uses __time64_t.
Result:
If you still want to use software from the last millenium to handle dates beyond 2038 you can use the CMonthCalCtrl when using only functions that accept SYSTEMTIME and COleDateTime parameters.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
