|
I have an encryption routine using Crypto API. Everything in my code works fine as long as I don't save the encrypted value to an Oracle Database. The Oracle Database character set does not support some of the character in the character set that Crypto API uses to Encrypt.
Is there a way to change the character set that Crypto API uses or to convert it in C++? The character set that I need is ISO 8859-1 West European 8-bit character set.
Thanks!!
HckygirlOH
|
|
|
|
|
You can either save it to an Oracle BLOB field, which is proper for binary data, or, if you really need to write it to a (var)char2 field, you may encode it as a base64 string.
You can do it on anything you choose - from .bat to .net - A customer
|
|
|
|
|
Hi all,
I'm working on a project where I have a native (unmanaged) DLL that establishes itself as a filter for system-wide (global) mouse processing. The functional bit of code is this:
<br />
extern "C" __declspec(dllexport)<br />
HHOOK Hook(PFN_MOUSE_MOVE_CALLBACK callback)<br />
{<br />
if (!_hooked)<br />
{<br />
_hooked = true;<br />
_mouseMoveCallback = callback;<br />
_hhk = SetWindowsHookEx(WH_MOUSE, SystemMouseProc, _hinstance, 0);<br />
return _hhk;<br />
}<br />
else<br />
return (HHOOK)NULL;<br />
}<br />
The argument is intended to be used in the actual mouse processing as follows:
<br />
LRESULT CALLBACK SystemMouseProc (int code, WPARAM wparam, LPARAM lparam)<br />
{<br />
if (code >= 0)<br />
{<br />
MOUSEHOOKSTRUCT* mouse = (MOUSEHOOKSTRUCT*)lparam;<br />
<br />
if (_mouseMoveCallback != NULL)<br />
_mouseMoveCallback(mouse->pt.x, mouse->pt.y);<br />
<br />
}<br />
return CallNextHookEx(_hhk, code, wparam, lparam);<br />
}<br />
The problem I'm hitting is that because it's a global hook, this DLL is "injected" (to use Microsoft's verbiage) into each process after it's initially installed by my EXE (which happens to be managed code, though I don't think it affects anything). This makes sense and is in fact what I want, EXCEPT for the fact that I want my callback to work when the thread of execution changes.
When the implementation of SystemMouseProc is changed to just dump to a file, everything's great:
<br />
FILE* stream;<br />
if ((stream = fopen("c:\\hook.txt", "a+")) != NULL)<br />
{<br />
fprintf(stream, "x: %d, y: %d\n", mouse->pt.x, mouse->pt.y);<br />
fclose(stream);<br />
}<br />
Heaps of mouse coordinates.
I guess what I'm trying to do is get some shared chunk of memory between all "instances" (is that the right word?) of my DLL so that regardless of the current process it's running in, my desired callback function can always be called. Right now, if the mouse is over any other program than the original caller, _mouseMoveCallback != NULL evaluates to false and nothing happens.
I've considered falling back on the stream method and just connecting a network socket to localhost between the DLL and calling EXE, but that really didn't seem like the best way to go if it could be helped.
Here's all the code for the DLL. TIA if you can help!
-T
<br />
#include "stdafx.h"<br />
#include "stdio.h"
<br />
<br />
LRESULT CALLBACK SystemMouseProc (int code, WPARAM wparam, LPARAM lparam);<br />
<br />
<br />
typedef void (__stdcall* PFN_MOUSE_MOVE_CALLBACK)(int, int);<br />
<br />
<br />
HHOOK _hhk = 0;<br />
HINSTANCE _hinstance = 0;<br />
bool _hooked = false;<br />
PFN_MOUSE_MOVE_CALLBACK _mouseMoveCallback = NULL;<br />
<br />
<br />
BOOL APIENTRY DllMain (HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved)<br />
{<br />
if (ul_reason_for_call == DLL_PROCESS_ATTACH)<br />
{<br />
if (_hinstance == 0)<br />
{<br />
_hinstance = (HINSTANCE)hModule;<br />
FILE* stream;<br />
if ((stream = fopen("c:\\hook.txt", "a+")) != NULL)<br />
{<br />
fprintf(stream, "Process Attached %d\n", (int)_hinstance);<br />
fclose(stream);<br />
}<br />
}<br />
}<br />
return TRUE;<br />
}<br />
<br />
extern "C" __declspec(dllexport)<br />
HHOOK Hook(PFN_MOUSE_MOVE_CALLBACK callback)<br />
{<br />
if (!_hooked)<br />
{<br />
_hooked = true;<br />
_mouseMoveCallback = callback;<br />
_hhk = SetWindowsHookEx(WH_MOUSE, SystemMouseProc, _hinstance, 0);<br />
return _hhk;<br />
}<br />
else<br />
return (HHOOK)NULL;<br />
}<br />
<br />
extern "C" __declspec(dllexport)<br />
void Unhook()<br />
{<br />
if (_hooked)<br />
UnhookWindowsHookEx(_hhk);<br />
<br />
return;<br />
}<br />
<br />
<br />
LRESULT CALLBACK SystemMouseProc (int code, WPARAM wparam, LPARAM lparam)<br />
{<br />
if (code >= 0)<br />
{<br />
MOUSEHOOKSTRUCT* mouse = (MOUSEHOOKSTRUCT*)lparam;<br />
<br />
if (_mouseMoveCallback != NULL)<br />
_mouseMoveCallback(mouse->pt.x, mouse->pt.y);<br />
<br />
}<br />
return CallNextHookEx(_hhk, code, wparam, lparam);<br />
}<br />
|
|
|
|
|
I'm working on a GUI program in Dev-C++, but I keep getting the following compiler errors:
246 music1b.cpp
C:\DEV-C_~1\Include\lvp\gui_bot.h: In function `int WinMain(HINSTANCE__ *, HINSTANCE__ *, CHAR *, int)':
474 c:\dev-c_~1\include\lvp\gui_bot.h
warning: converting NULL to non-pointer type
474 c:\dev-c_~1\include\lvp\gui_bot.h
warning: converting NULL to non-pointer type
(Line 246 is the bottom of the program where I include gui\bot.h)
Is is possible that there's something wrong with my gui_bot.h file? Do I need a fresh copy of it, or could the problem be with my code?
|
|
|
|
|
I don't see an actual error in the messages, just warnings (unless you have warnings set to be treated as errors). Are there no other messages?
- Mike
|
|
|
|
|
Those are the only messages I'm getting, but it's not letting me execute. The linker gives me:
g++: C:\Dev-C++\Borland\BCC55\Lib\PSDK\winmm.lib: linker input file unused since linking not done
but I don't know if that's relevent or not. Any ideas?
|
|
|
|
|
That warning is harmless -- it's just saying that a library was not included since it never got to the link stage.
Sounds like the compilation proceeded normally, but it never created an executable for some reason. Perhaps it's a problem with project settings... I'm not familiar enough with Dev-C++ to really debug any further, sorry 
- Mike
|
|
|
|
|
hi..
i am about to write a report on Microsoft CSocket and CAsyncSocket.
I've heard from ppl that CSocket and CAsyncSocket sucks!!!
i would like to request ppl here who have used CSocket and CAsyncSocket to please provide me with COMMENTS and LINKS which can prove that CSocket and CAsyncSocket are not worth using and contains loopholes...
Would you be pls as kind as to gimme some LINKS and COMMENTS on HOW and WHY do CSocket and CAsyncSocket sucks..!
Tks a lot..
With Regards
Joseph R. Thomas
Have a Super Blessed Day!
-------------------------
For God has not given us a spirit of fear, but of power and of love and of a sound mind.
2 Timothy 1:7
|
|
|
|
|
Read the Winsock Programmers FAQ (Google for it). There is a text there about why it's bad.
Rickard Andersson
Here is my card, contact me later!
UIN: 50302279
Sonork: 37318
Interests: C++, ADO, SQL, Winsock, 0s and 1s
|
|
|
|
|
I use the GDI+ in VC7 to save an image. It work very well when I want to save as tiff, png and jpeg. But the program fails to do so when I want to save as wmf, exif and emf.
I consult the msdn and find in
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdicpp/GDIPlus/UsingGDIPlus/UsingImageEncodersandDecoders/Retrievingthe.asp
it said that
"The function GetEncoderClsid in the following example receives the Multipurpose Internet Mail Extensions (MIME) type of an encoder and returns the class identifier (CLSID) of that encoder. The MIME types of the encoders built into Microsoft Windows GDI+ are as follows:
image/bmp
image/jpeg
image/gif
image/tiff
image/png"
Thus it seems that we could not save an image as wmf, exif or emf format. But I also find that
http://www.codeproject.com/cs/media/imagconvert.asp?target=conver
In the C#, we could save an image as wmf, exif or emf format with no pains.
Does anyone know how to solve this puzzle? Thanks a lot!
|
|
|
|
|
Maybe VS.NET adds encoders?
Have you tried enumerating the encoders and getting the available list?
Steve S
|
|
|
|
|
Here is the function GetImageCLSID
static int GetImageCLSID(const WCHAR* format, CLSID* pCLSID)
{
UINT num = 0; // number of image encoders
UINT size = 0; // size of the image encoder array in bytes
ImageCodecInfo* pImageCodecInfo = NULL;
GetImageEncodersSize(&num, &size);
if(size == 0)
return -1; // Failure
pImageCodecInfo = (ImageCodecInfo*)(malloc(size));
if(pImageCodecInfo == NULL)
return -1; // Failure
GetImageEncoders(num, size, pImageCodecInfo);
for(UINT j = 0; j < num; ++j)
{
if( wcscmp(pImageCodecInfo[j].MimeType, format) == 0 )
{
*pCLSID = pImageCodecInfo[j].Clsid;
free(pImageCodecInfo);
return j; // Success
}
}
free(pImageCodecInfo);
return -1; // Failure
}
|
|
|
|
|
Is there a way that i can set/change a control extended style at run time without having to create it again (Create(...),CreateEx(...))?
|
|
|
|
|
Some styles can be changed at run-time, some cannot.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
ModifyStyleEx
Regards,
Alvaro
Hey! It compiles! Ship it.
|
|
|
|
|
In general, ModifyStyle and ModifyStyleEx. However, the list control has its own extended styles that must be set through SetExtendedStyle.
ModifyStyle(Ex) works by calling SetWindowLong with the GWL_STYLE or GWL_EXSTYLE parameters as appropriate.
Some of the settings changed by this method won't take effect until either SetWindowPos is called, and some styles can't be changed after creation.
|
|
|
|
|
I was curious if writing code using more traditional C-like character parsing and handling is more efficient under high volume scenarios than using STL strings?
for instance, if we use strtok and all those string manipulation stuff that C and C++ offer, do they perform better than using STL string and its various functions, if efficiency is of critical concern?
thanks
|
|
|
|
|
To help answer, I'll let you know a little secret: The two words "STL" and "efficiency" are mutually exclusive.
|
|
|
|
|
The simplest answer has to be 'suck it and see'.
I seem to recall that Herb Sutter did some trials and discovered that STL tended to be rarely worse and sometimes a bit better than if you'd written it by hand. They're either on his site[^] or at C/C++ Users' Journal[^].
|
|
|
|
|
anonymous wrote:
I was curious if writing code using more traditional C-like character parsing and handling is more efficient under high volume scenarios than using STL strings?
They may be faster in error free situations.
However consider error handling and ease of coding / maintainance before you go away from STL strings. Use STL until your profiling shows you that STL is the bottleneck.
It's likely that algorithmic peformance for parsing may make a bigger impact. For parsing code look at boost::regex or boost::spirit, or depending on what you need maybe flex and bison (lex and yacc) or a scripting language.
If you can keep you head when all about you
Are losing theirs and blaming it on you;
If you can dream - and not make dreams your master;
If you can think - and not make thoughts you aim;
Yours is the Earth and everything that's in it.
Rudyard Kipling
|
|
|
|
|
If efficiency is critical, I wouldn't use neither STL nor STL C++ library. As suggested before, I would go for a library or parsing generator toolkit capable of generating a FSA parser.
You can do it on anything you choose - from .bat to .net - A customer
|
|
|
|
|
When you get down to it, you can not know which is better until you test it. Try to do some small scale mock ups of the code and test the speed.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Hi,
I'm trying to give a list box on a dialog a tool tip using CToolTipCtrl.
Here's the code I used:
CToolTipCtrl tooltip;
tooltip.Create(this,TTS_ALWAYSTIP); //this is the dialog having the dialog
listbox=(CListBox *)GetDlgItem(ID_LISTBOX);
//Get client area of list box relative to the dialog
::GetWindowRect(listbox->m_hWnd,&rect);
BOOL b=tooltip.AddTool(this, IDS_STRING1, &rect, ID_LISTBOX);
tooltip.Activate(TRUE);
tooltip.SetDelayTime(1);
However, when I move the mouse over the list box, no tool tip comes up.
Any suggestions would appreciated.
Thanks.
Martin
|
|
|
|
|
The reason is most likely because your tooltip object is being constructed on the stack, right inside your function, and then it goes away as soon as the function exits. Two suggestions:
1. Make the tooltip object a member of the class, instead of a local variable.
OR
2. If your function is only called ONCE in the entire program, make your tooltip object static so that it doesn't go away (until the program exits):
static CToolTipCtrl tooltip;
I don't know if the rest of the code is fine, but you can start with this.
Regards,
Alvaro
Hey! It compiles! Ship it.
|
|
|
|
|
I think Alvaro is right!!!
This cud be the reason. If the problem still persists, use the 2 parameter form of AddTool(...). Dont the specify the CRect. Once you specify the CRect attribute, then the tooltip is binded to that rectangle.
"A robust program is resistant to errors -- it either works correctly, or it does not work at all; whereas a fault tolerant program must actually recover from errors."
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
