|
Hi,
This Microsoft example is actually using the SHA1 hash using the CryptoAPI functions.
Example C Program: Duplicating a Hash[^]
You should be able to easily modify it and remove the code for duplicating the hash. All you would need is the original.
Best Wishes,
-David Delaune
|
|
|
|
|
|
Hi all,
I am using fwrite to save some images in while loop.
so i a can increment the file in fopen..
like 1.raw,2.raw...3....10
As first paramater is taking const char*.
If i take as a CString i am not able to get.
I tried the below code
CString FileName = "D:\\"
sprintf_s(ch,"%d",i++);
FileName=ch;
FileName+=".raw";
FileName=str+FileName;
then converted CString to char*
const TCHAR* cstr = (LPCTSTR)FileName;
It is showing as bad pointer
Is there any other way to increment the file name and save all images
Here is the Below code:
FILE *fp_ara;
while(1)
{
fp_ara=fopen ("D:\\1.raw","wb");
fwrite(Data,2,1024*1024,fp_ara);
if(fp_ara == NULL)
exit(1);
fclose(fp_ara);
}
Thank you
Sharan
|
|
|
|
|
me think you are over-complicating things.
how about something like :
for (int i = 0; i < numberOfFile; i++ )
{
CString filename;
filename.Format("c:\\path\\to\\file\\%i.raw", i);
FILE* fp = fopen( filename, ... );
fclose(fp);
}
Watched code never compiles.
|
|
|
|
|
I would like to add here that by default the unicode version of CString will be used.
This means that you're mixing unicode and non-unicode strings in your code.
This will not give you the desired results.
If you only want non-unicode characters, you can use CStringA instead of CString.
If you want unicode characters, then you will need to change const char* to const wchar_t*, fopen to wfopen and prefix strings with L (L".raw").
|
|
|
|
|
Hi!
While running my application,the execution pointer goes to the following line in the file xstring and crashes.
int __CLR_OR_THIS_CALL compare(const _Myt& _Right) const
{
return (compare(0, _Mysize, _Right._Myptr(), _Right.size()));
}
How to fix this crash?
|
|
|
|
|
it's impossible for anyone here to say. we need more information.
how are you calling compare ?
|
|
|
|
|
some times it crashes to a file called xhash in "Microsoft Visual Studio/VC/include" path. The execution pointer points to the following line:
inline iterator _Get_iter_from_vec(const _Myvec_value_type &_Iter) const
{
return _Iter;
}
Following is the call graph contents:
winRTSimpleApp.exe!stdext::_Hash<stdext::_Hmap_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,Variant *,stdext::hash_compare<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >,std::allocator<std::pair<std::basic_string<char,std::char_traits<char>,std::allocator<char> > const ,Variant *> >,0> >::_Get_iter_from_vec(const std::list<std::pair<std::basic_string<char,std::char_traits<char>,std::allocator<char> > const ,Variant *>,std::allocator<std::pair<std::basic_string<char,std::char_traits<char>,std::allocator<char> > const ,Variant *> > >::_Iterator<0> & _Iter={...}) Line 279 + 0x3 bytes C++
winRTSimpleApp.exe!stdext::_Hash<stdext::_Hmap_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,Variant *,stdext::hash_compare<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >,std::allocator<std::pair<std::basic_string<char,std::char_traits<char>,std::allocator<char> > const ,Variant *> >,0> >::lower_bound(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & _Keyval="visible") Line 599 + 0x1f bytes C++
winRTSimpleApp.exe!stdext::_Hash<stdext::_Hmap_traits<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,Variant *,stdext::hash_compare<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::less<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >,std::allocator<std::pair<std::basic_string<char,std::char_traits<char>,std::allocator<char> > const ,Variant *> >,0> >::find(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & _Keyval="visible") Line 579 + 0x10 bytes C++
winRTSimpleApp.exe!VariantDB::GetVarIfExists(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & keyName="visible") Line 40 C++
winRTSimpleApp.exe!VariantDB::GetVar(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & keyName="visible") Line 69 + 0xc bytes C++
winRTSimpleApp.exe!Entity::GetVar(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & varName="visible") Line 72 + 0x35 bytes C++
winRTSimpleApp.exe!checkCollision(VariantList * pVList=0x0c9a8900) Line 113 + 0x3a bytes C++
winRTSimpleApp.exe!boost::detail::function::void_function_invoker1<void (__cdecl*)(VariantList *),void,VariantList *>::invoke(boost::detail::function::function_buffer & function_ptr={...}, VariantList * a0=0x0c9a8900) Line 111 + 0x9 bytes C++
winRTSimpleApp.exe!boost::function1<void,VariantList *>::operator()(VariantList * a0=0x0c9a8900) Line 989 + 0x17 bytes C++
winRTSimpleApp.exe!boost::signals::detail::call_bound1<void>::caller<VariantList *,boost::function<void __cdecl(VariantList *)> >::operator()<boost::signals::detail::connection_slot_pair>(const boost::signals::detail::connection_slot_pair & slot={...}) Line 120 C++
winRTSimpleApp.exe!boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound1<void>::caller<VariantList *,boost::function<void __cdecl(VariantList *)> >,boost::signals::detail::named_slot_map_iterator>::dereference() Line 61 + 0x1b bytes C++
winRTSimpleApp.exe!boost::iterator_core_access::dereference<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound1<void>::caller<VariantList *,boost::function<void __cdecl(VariantList *)> >,boost::signals::detail::named_slot_map_iterator> >(const boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound1<void>::caller<VariantList *,boost::function<void __cdecl(VariantList *)> >,boost::signals::detail::named_slot_map_iterator> & f={...}) Line 517 C++
winRTSimpleApp.exe!boost::iterator_facade<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound1<void>::caller<VariantList *,boost::function<void __cdecl(VariantList *)> >,boost::signals::detail::named_slot_map_iterator>,boost::signals::detail::unusable,boost::single_pass_traversal_tag,boost::signals::detail::unusable const &,int>::operator*() Line 634 + 0xe bytes C++
winRTSimpleApp.exe!boost::detail::postfix_increment_proxy<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound1<void>::caller<VariantList *,boost::function<void __cdecl(VariantList *)> >,boost::signals::detail::named_slot_map_iterator> >::postfix_increment_proxy<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound1<void>::caller<VariantList *,boost::function<void __cdecl(VariantList *)> >,boost::signals::detail::named_slot_map_iterator> >(const boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound1<void>::caller<VariantList *,boost::function<void __cdecl(VariantList *)> >,boost::signals::detail::named_slot_map_iterator> & x={...}) Line 145 + 0x2b bytes C++
winRTSimpleApp.exe!boost::operator++<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound1<void>::caller<VariantList *,boost::function<void __cdecl(VariantList *)> >,boost::signals::detail::named_slot_map_iterator>,boost::signals::detail::unusable,boost::single_pass_traversal_tag,boost::signals::detail::unusable const &,int>(boost::iterator_facade<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound1<void>::caller<VariantList *,boost::function<void __cdecl(VariantList *)> >,boost::signals::detail::named_slot_map_iterator>,boost::signals::detail::unusable,boost::single_pass_traversal_tag,boost::signals::detail::unusable const &,int> & i={...}, int __formal=0) Line 734 C++
winRTSimpleApp.exe!boost::last_value<void>::operator()<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound1<void>::caller<VariantList *,boost::function<void __cdecl(VariantList *)> >,boost::signals::detail::named_slot_map_iterator> >(boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound1<void>::caller<VariantList *,boost::function<void __cdecl(VariantList *)> >,boost::signals::detail::named_slot_map_iterator> first={...}, boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound1<void>::caller<VariantList *,boost::function<void __cdecl(VariantList *)> >,boost::signals::detail::named_slot_map_iterator> last={...}) Line 49 + 0x12 bytes C++
winRTSimpleApp.exe!boost::signal1<void,VariantList *,boost::last_value<void>,int,std::less<int>,boost::function<void __cdecl(VariantList *)> >::operator()(VariantList * a1=0x0c9a8900) Line 354 + 0xbb bytes C++
winRTSimpleApp.exe!MessageManager::Deliver(Message * m=0x0c9a8888) Line 253 C++
winRTSimpleApp.exe!MessageManager::Update() Line 286 C++
winRTSimpleApp.exe!BaseApp::Update() Line 181 C++
winRTSimpleApp.exe!App::Update() Line 225 C++
winRTSimpleApp.exe!WinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, char * lpCmdLine=0x001d3560, int nCmdShow=1) Line 1019 + 0x20 bytes C++
winRTSimpleApp.exe!__tmainCRTStartup() Line 263 + 0x2c bytes C
winRTSimpleApp.exe!WinMainCRTStartup() Line 182 C
kernel32.dll!768ded6c()
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
ntdll.dll!778537f5()
ntdll.dll!778537c8()
winRTSimpleApp.exe!boost::signals::detail::bound_objects_visitor::decode<TyperComponent *>(TyperComponent * const & t=, long __formal=1946221693) Line 92 + 0x10 bytes C++
f87d83f8()
|
|
|
|
|
hi every body am back .
how can i load the image by using picture control in an SDI and even in dialog box Application .
thanking you
sarfaraz 
|
|
|
|
|
If you have added a picture control to your dialog using the dialog editor, gave that control an ID (it is initialized with IDC_STATIC) and add a CStatic member variable for the control to your dialog class.
Then load the bitmap from your resources from within OnInitDialog():
m_staticPic.SetBitmap(::LoadBitmap(NULL, MAKEINTRESOURCE(OBM_PIC1)));
See also CStatic::SetBitmap in the MFC library reference [^].
|
|
|
|
|
I have a C++ class that implements a interface (ErrorInterface), because of old design. My class don't uses one of the methods (reset) in this interface but I have added an empty implementation because I don't want the class to be abstract. When I build the project I get warnings "unused parameters 'error'". Can I remove this warning?
class ErrorInterface
{
public:
virtual void reset(ErrorType error) = 0;
};
void MyClass::reset(ErrorType error)
{
}
|
|
|
|
|
Either of the following methods will remove the warning -
void MyClass::reset(ErrorType)
{
}
OR
void MyClass::reset(ErrorType error)
{
error;
}
Or you can use the UNREFERENCED_PARAMETER macro which does the same as the second method -
void MyClass::reset(ErrorType error)
{
UNREFERENCED_PARAMETER(error);
}
|
|
|
|
|
|
We have a in-house program written in win32 API. It works OK on Windows XP. When running the program on Windows Vista and 7 however, we found a strange behavior that the toolbar and status bar disappear during client area update. The odd is more pronounced when object tracking is enabled which leads to high refresh rate of client area. This behavior does not occur on XP.
I guess the cause is that the toolbar and status bar is put inside the client area, so they are not redrawn when client area is updated. But I can not figure the issue out.
The main program structure is a typical win32 application found in C. Petzold's book. The toolbar and status bar is created when handing WM_CREATE message.
// Create the toolbar control.
static HWND hWndToolbar;
hWndToolbar = CreateWindowEx(
0, // No extended styles.
TOOLBARCLASSNAME, // Class name for the toolbar.
NULL, // No default text.
WS_CHILD | TBSTYLE_WRAPABLE | TBSTYLE_FLAT | TBSTYLE_LIST, // Styles and defaults.
0, 0, 0, 0, // Standard toolbar size and position.
hWndParent, // Parent window of the toolbar.
NULL /*(HMENU)iToolBarID*/, // Toolbar ID.
hInst, // Current instance.
NULL); // No class data.
// Create statusbar control
static HWND hWndStatusBar;
hWndStatusBar = CreateWindowEx(
0, // no extended styles
STATUSCLASSNAME, // name of status bar class
(LPCTSTR) NULL, // no text when first created
WS_CHILD | WS_VISIBLE, // includes a sizing grip
0, 0, 0, 0, // ignores size and position
hWndParent, // handle to parent window
NULL/*(HMENU)nStatusID*/, // child window identifier
hInst, // handle to application instance
NULL); // no window creation data
|
|
|
|
|
Are you updating the toolbar and statusbar during normal windows operations like moving and resizing of your main window? Do you have a child window in your main window or do you use the 'free' area of your main window for display of your data?
BTW please put your code snippets between <pre> tags so it is more readable, like this:
static HWND hWndStatusBar;
hWndStatusBar = CreateWindowEx(
0, STATUSCLASSNAME, (LPCTSTR) NULL, WS_CHILD | WS_VISIBLE, 0, 0, 0, 0, hWndParent, NULL, hInst, NULL);
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
Hi, thanks for your help.
For the first question, I'm not updating toolbar and statusbar. As they are both child windows of main window. I expected they might be automatically updated by main window.
As for your second question, I use the "free" area of main window and there is no child window in main window.
Do I suggest me to either update toolbar and statusbar every time the main window is updated, or create a child window inside main window?
I guess the issue might result from the inproper layout that the toolbar and statusbar are overlayed on the client area of main window, and I use InvalidateRect(hwndParent, NULL, FALSE) to update the client area. But the toolbar and statusbar are not automatically updated by InvalidateRect. Which way is better? or is there any other method to fix the issue? I'm looking forward to your further help.
|
|
|
|
|
Lianqing wrote: I use InvalidateRect(hwndParent, NULL, FALSE) to update the client area.
Which means you paint over the entire client area of your window including the space taken by the toolbar and statusbar. This is not the best way to do it. Whether you use a client window or the client space of the main window you need to adjust your sizes to take account of the toolbar and statusbar. The top left of your client space needs to be adjusted by the height of the toolbar and its height by the height of the statusbar. It's generally better to follow the Windows model and use a client window.
Unrequited desire is character building. OriginalGriff
I'm sitting here giving you a standing ovation - Len Goodman
|
|
|
|
|
I had follow code :
double dbl = 24.000560700;
CString sTemp,sDecimal;
sTemp.Format(_T("%0.16f"),dbl);
SetWindowText(sTemp);
and result is 24.0005607000000010 ... not 24.000560700, why ?
|
|
|
|
|
because the number cannot be precisely represented in binary, and when it gets printed out, the value will be displayed with that "error".
See this : http://support.microsoft.com/kb/42980[^]
Watched code never compiles.
|
|
|
|
|
Why does this question keep coming up? ...please do a search before posting questions... I'm sure we've answered this about 10-20 times in a year's time frame...
|
|
|
|
|
Because you asked for 16 digits, it gave you 16 digits.
The "imprecision" is in producing the OUTPUT, the conversion of the binary / computer representation of the number into the string of characters that you display. This is true regardless of whether it is you printing the value or the debugger displaying it for you. Both processes need to take the binary value and convert it to a string of characters for your eyes.
Computer binary representations (Base 2) and printed represetnations (in Base 10) are inherently incompatible and can only be approximated. You control the approximation with the format specifier for how many digits you want to see.
You have also made a basic assumption that is also flawed. You assume this program statement produces a "precise" value:
double dbl = 24.000560700; when in fact, the compiler has to take this character representation of a number, convert it from base 10 to the binary representation of a floating point number, base 2, and put it into the object file to be included in the program. Because of the what I said above, conversion from text to binary form (compilation) or from binary form to text (printf) each provide some level of "imprecision" or "approximation" that varies in the least significant digits, as you've discovered.
|
|
|
|
|
"%0.16f" means there will be 16 digits after the "." for result.
"%0.9f" is what you need!
|
|
|
|
|
Because the double data type is a convenient approximate representation (see here, it is quite formative)[^]) of real numbers. Computers memory is finite, it cannot map infinite sets like real numbers (or even natural numbers).
Veni, vidi, vici.
|
|
|
|
|
|
Yes, but I don't know always how many decimal exist ...
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
