|
Thanks for the suggestion though! ...it gave me the idea to finally fix my little problem.
|
|
|
|
|
Yourwelcome. 
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> //TODO: Implement signature here<
|
|
|
|
|
Hi
Coding Lang TurboC.
How can I open a 'workshhet'
also how to write a file which will directly open wit XL
=mangal ho
|
|
|
|
|
There are lots of CodeProject articles and Google tips on these subjects. Try here[^] and here[^].
The best things in life are not things.
|
|
|
|
|
I'm having trouble setting precision for floats using ostringstream.
I want all floats to have one digit after the decimal point (i.e 1.0f and 10.0f to be formated as "1.0" and "10.0"). However the 10 is coming out as "10.".
Is there any way to do it?
This is my code:
ostringstream os;
float incRate = 1.0f;
os.setf(ios_base::showpoint);
os << "incRate: " << setprecision(2) << incRate <<
modified on Tuesday, June 28, 2011 10:53 AM
|
|
|
|
|
Seems to be a fairly common hurdle when dealing with the streams.
Found an answer on stackOverflow, it's a requirement that "fixed" is used before trying to
set the precision. If this is not done, the call to setprecision will specify the _total_ number of digits to be displayed. Occurring after "fixed", it will specify the number of places after the decimal point to display.
Found it here[^].
Code:
#include <iostream>
#include <iomanip>
using namespace std;
int main()
{
float incRate = 10.0f;
cout << fixed << setprecision(2) << 12.12123 << endl << setprecision(5) << 12.12123;
return 0;
}
Output
12.12
12.12123
Process returned 0 (0x0) execution time : 0.023 s
Press any key to continue.
Cheers 
|
|
|
|
|
|
My pleasure. Now I've the answer before I ask myself the same question re: streams.
Thanks
|
|
|
|
|
I am doing project migration from VC6 to VS10.
In one of the project,_atoi64 conversion is used.
This CRT function behavior is differing from VC6.
In VC6 and VS10 this CRT function call goes to atox.c.
In VC6,this CRT function calls __int64 __cdecl _atoi64 in atox.c.Here,they just accumulate the digits and returning the value.They didnt check any limits for generated value.
But,In VS10 this CRT function calls __int64 __cdecl _tstoi64 in atox.c.Here,they are checking the generated value with Max_VAL (_UI64_MAX - 0xffffffffffffffffui64 ).if the generated value exceeds the maximum value,they are just replacing with _I64_MAX - 9223372036854775807i64.
Due to this some Autotests are failing.
Is any other equivalent to _atoi64 in VS10 or any other suggestions please..
Thanks,
Gomathy L
|
|
|
|
|
No disrespect but let me see if I have this straight.
You have some old tests that have data that is outside the valid range for __int64.
These tests are now failing because somebody (RTL) is checking for valid data.
You want to go back to accepting invalid data so that the test "pass".
What good are the tests if they allow invalid data to go through?
Why aren't you more concerned about the fact that older versions of your application let invalid data go through without any way of detecting it?
|
|
|
|
|
I front with a strange problem : I have a MDI app, and a CMDIChildWnd that create a static split window where I stretch in left side e tree view and in the right side three listviews ... in one of these, I want to reflect a message :
ON_NOTIFY_REFLECT_EX(LVN_COLUMNCLICK, OnColumnclick)
but here :
LRESULT CDataExplorerServiceView::OnColumnclick(NMHDR* pNMHDR, LRESULT* pResult)
{
NM_LISTVIEW* phdr = reinterpret_cast<NM_LISTVIEW*>(pNMHDR);
m_nColumnSort = phdr->iSubItem;
*pResult = 0;
TRACE("++++%d\n",m_nColumnSort);
return *pResult;
}
when I clicked on header, everytime I get twice TRACE ( not doubleclick, but app run twice this handler ... why ? I'm stuck here and I have no ideea where to search ... Thank you.
|
|
|
|
|
Flaviu2 wrote: when I clicked on header, everytime I get twice TRACE ( not doubleclick, but app run twice this handler ... why ?
Once for the old state and another for the new state, perhaps.
Did you try looking at the phdr->uNewState, phdr->uOldState, and phdr->uChanged fields each time OnColumnclick() is called?
"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
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
Yes, but without reflection, the handler is executed once ... 
|
|
|
|
|
Firstly, I've very little experience with MFC and realize my answer may not be helpful.
However, when I fire up a plain ol' win32 program and click on the header of a list-view, there are indeed two WM_NOTIFY in a row in the messages list.
Looking at the messages in Spy++, I get:
....
....
<00824> 01BC0A0C S WM_NOTIFY idCtrl: 0 pnmh:0028DD08
<00825> 01BC0A0C R WM_NOTIFY
....
....
Checking the help for spy++, gives this explanation of the 'S' and the 'R'
Code Meaning
P The message was posted to the queue with the PostMessage function. No information is available concerning the ultimate disposition of the message.
S The message was sent with the SendMessage function. This means that the sender doesn’t regain control until the receiver processes and returns the message. The receiver can, therefore, pass a return value back to the sender.
s The message was sent, but security prevents access to the return value.
R Each ‘S’ line has a corresponding ‘R’ (return) line that lists the message return value. Sometimes message calls are nested, which means that one message handler sends another message.
Reading the code meanings seems to suggest that the second instance, the 'R' one is the return value of a call to SendMessage (when the child notified the parent)
Now I really am intrigued...
Are you able to report on what spy++ tells you about the messages being passed in your program?
|
|
|
|
|
Interesting ideea, thank you so much, I will try to test it, I never use Spy++ ... I reproduce sitation in a small test application here[^]... can be seen sitation in debug mode. Hmm ... weird.
|
|
|
|
|
That's okay, I forget who first directed me towards that tool. It sure was helpful when I was busy trying to hack through win32 coding all that time ago.
I've just tried to compile that program in debug mode, however am presented with this "do not pass go" message:
1>c:\users\enhzflep\documents\code\test2\my3view.cpp(30): error C2440: 'static_cast' : cannot convert from 'LRESULT (__thiscall CMy3View::* )(NMHDR *,LRESULT *)' to 'BOOL (__thiscall CCmdTarget::* )(NMHDR *,LRESULT *)'
Which perhaps unsurprisingly points to the below code:
BEGIN_MESSAGE_MAP(CMy3View, CListView)
ON_NOTIFY_REFLECT_EX(LVN_COLUMNCLICK, OnColumnclick)
END_MESSAGE_MAP()
Tried it with VS2010.
Upon digging deeper, I came across this page[^] at msdn, that seems to indicate that your function OnColumnClick should have a return-type of BOOL
Hmmmmmm - just tried editing the definition of the OnColumnClick function so that it has a return type of BOOL, instead of LRESULT - that worked!
Now, finally I can see where you're coming from. Rather than the pair of messages I was seeing in my app, I can see that your app is generating 2 pairs of messages. It seems that the messages are being sent from two different controls 
Each click on a column header is giving me (amongst other messages) this:
<00323> 015A080C S WM_NOTIFY idCtrl:59680 pnmh:0040E220
<00324> 015A080C R WM_NOTIFY
<00325> 015A080C S WM_NOTIFY idCtrl: 0 pnmh:0040F96C
<00326> 015A080C R WM_NOTIFY
Perhaps an investigation into what these two controls are is in order..
Perhaps one of these may help?
(1)[^]
(2)[^] (In german, use Google translate - for some reason had trouble pasting the url of the translated page)
|
|
|
|
|
enhzflep wrote: It seems that the messages are being sent from two different controls
Each click on a column header is giving me (amongst other messages) this:
< 00323> 015A080C S WM_NOTIFY idCtrl:59680 pnmh:0040E220
< 00324> 015A080C R WM_NOTIFY
< 00325> 015A080C S WM_NOTIFY idCtrl: 0 pnmh:0040F96C
< 00326> 015A080C R WM_NOTIFY
Perhaps an investigation into what these two controls are is in order..
The ID of the header control within a listview is always 0.
"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
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
:slaps his head:
Of course! Thanks David.
|
|
|
|
|
Hi All,
Can you help me to get clsid from GUID. I tried in google. didn't find. I'm new to cpp.
Thanks in advance..
|
|
|
|
|
You have a GUID of what?
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]
|
|
|
|
|
#include <windows.h>
#include <stdio.h>
void PlayWithAccess(IUnknown *p);
void CallOpenDatabase(IDispatch *d);
int main(int argc, char* argv[])
{
HRESULT hRet;
CLSID clsid;
IUnknown *p=NULL;
hRet=CoInitialize(NULL);
if(FAILED(hRet)) {
printf("It Failed...\n");
return 1;
}
hRet=CLSIDFromProgID(L"Access.Application",&clsid);
if(FAILED(hRet)){
printf("CLSID Illegal...\n");
CoUninitialize();
return 1;
}
hRet=CoCreateInstance(&clsid, NULL, CLSCTX_ALL, &IID_IUnknown, (IUnknown **)&p);
if(FAILED(hRet)) {
printf("Create Failed....");
CoUninitialize();
return 2;
}
PlayWithAccess(p); p->lpVtbl->Release(p);
CoUninitialize();
return 0;
}
void PlayWithAccess(IUnknown *p)
{
char buf[100];
IDispatch *d=NULL;
HRESULT hret;
hret=p->lpVtbl->QueryInterface(p,&IID_IDispatch,(void **)&d);
if(FAILED(hret)){
printf("DispatchID Failed...\n");
sprintf(buf,"DispatchID failed w/err 0x%08lx", hret);
MessageBox(NULL, buf, "DispatchID", 0x10010);
return;
}
printf("Got the IDispatch Interface from Object...\n");
CallOpenDatabase(d);
printf("Enter Return:");
gets(buf);
d->lpVtbl->Release(d);
}
void CallOpenDatabase(IDispatch *d)
{
VARIANTARG args[2];
BSTR DBLocation=SysAllocString(L"D:/project/C/c_ado/connDB02/Example.mdb");
OLECHAR *MethodName=L"OpenCurrentDatabase";
DISPID dispid=0;
HRESULT hret;
DISPPARAMS params;
DISPID ids[2]={1,0};
hret=d->lpVtbl->GetIDsOfNames(d,&IID_NULL,&MethodName,1,LOCALE_USER_DEFAULT,&dispid);
printf("Got a Dispatch Identifier....%x\n",dispid);
memset(args,0,sizeof(args));
args[0].vt=VT_BOOL;
args[0].boolVal=FALSE;
args[1].vt=VT_BSTR;
args[1].bstrVal=DBLocation;
memset(¶ms,0,sizeof(params));
params.cArgs=2;
params.rgvarg=args;
hret=d->lpVtbl->Invoke(d,dispid,&IID_NULL,LOCALE_USER_DEFAULT,DISPATCH_METHOD,¶ms,NULL,NULL,NULL);
if(FAILED(hret)) {
printf("Invoke Failed....\n");
}
SysFreeString(DBLocation);
}
How to do?thanks!
|
|
|
|
|
Couple of observations here
what's the problem? what error code are you getting? what sort of help do you require?
It's extremely unlikely anyone's going to copy your code, compile it and come back with the answer - sorry
A general suggestion, don't use Dispatch interfaces, they are the most unwieldy method of calling com objects, use the 'real' interface
Another one, if you have access to ATL, use CComPtr's to help wrap the pointers, and use OLE DB Client Templates to talk with Access
|
|
|
|
|
thank you answer my question
I think use C to Implement the Dispatch interface.But I find it's not.
|
|
|
|
|
I need to be able to stop COM port from sending the Morse code using space character from keyboard.
I use a button change event to execute the code sending function, however, I am unable to detect the keyboard since the sending function is still executing.
I tried to “insert” PostMessage custom WM_USER message but Windows still waits until the sending function is finished before recognizing the keyboard.
I am using PreTranslateMessage in MFC view.
Would adding another thread work?
I do not have much experience in multithreading, but willing to do it if it solves the problem.
Any other constructive suggestions will be appreciated.
Cheers
Vaclav
|
|
|
|
|
That may work... what you have going on is a classic case of a C/C++ blocking call keeping you from doing what you need... in which case the threading should help. I would however, move the COM interactions to their own thread and stop when needed instead of leaving the blocking call in the main thread.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
