|
Hi,
I've overide a WM_KEY and WM_GETDLGCODE of an CEdit to know when the user presse "enter" key like this :
UINT CMyEdit::OnGetDlgCode()
{
return DLGC_WANTALLKEYS;
}
void CMyEdit::OnKeyDown(UINT nChar, UINT nRepCnt, UINT nFlags)
{
if (nChar==0x0000000d)
Funtion();
CEdit::OnKeyDown(nChar, nRepCnt, nFlags);
}
this way, i can call Function() when user press "enter"... Unfortunalty, there is a "bip" (sound system) when the "enter" key is pressed...
Does anyone know how to disable this "bip" ??
Thanks yyou veru much
|
|
|
|
|
I am writing a C++ DLL which will be called by Visual Basic for Applications in Excel. Should I be using BOOL vs. bool as the type of arguments passed to/from the DLL. For some reason bool doesn't work ... Both C++'s true and false are interpreted as True in VB. Does anyone know why?
Is bool just a 1-byte character whereas BOOL is like an int? What is Boolean type in VB equivalent to in C++?
|
|
|
|
|
Anton A. Loukine wrote:
Should I be using BOOL vs. bool
BOOL
and tell the VB users to use a Long on their end.
-c
Image tools: ThumbNailer, Bobber, TIFFAssembler
|
|
|
|
|
So BOOL is a 32-bit integer?
|
|
|
|
|
Anton A. Loukine wrote:
So BOOL is a 32-bit integer?
yep.
it's #define'd as int or long, depending on which set of #include files you happen to pick up. but they're both 32 bits in Win32.
-c
Image tools: ThumbNailer, Bobber, TIFFAssembler
|
|
|
|
|
You should be using VARIANT_BOOL, which is a 2-byte type and the VB/VBA version of a boolean. Use the two constants VARIANT_TRUE and VARIANT_FALSE for the values.
--Mike--
THERE IS NO THERE IS NO BUT THERE IS
MAGIC PIXIE DUST BUSINESS GENIE CODE PROJECT
Homepage | RightClick-Encrypt | 1ClickPicGrabber
"You have Erica on the brain" - Jon Sagara to me
|
|
|
|
|
I am currently trying to perform a mathematical addition on two strings. I was curious if there were any built-in functions available for this. If not that is okay. Thx for any help.
|
|
|
|
|
Hi,
I've written a small application, very basic, that works on Windows Me, Windows XP and Windows 2000, but (I am told) crashes with the error "abnormal program termination" in Windows 98. The program uses the common control progress bar (and uses Initcommoncontrolsex etc to set it up), a ZipArchive library, and not really much more. I can't see why I might be getting this error.
I'm a fairly inexperienced programmer, so if somebody could tell me where I might start looking (the types of things I need to look at) in my program, or the general things that might cause a crash on Win98 where it works on other systems, I would be really grateful.
Thank you,
Keith B.
|
|
|
|
|
First check if it crashes on more than one Win98 system. The problem may be related to the user's PC which just happens to run Win98, and not Win98 itself. I'd look for missing files that the program expects to find. It's possible that you may not have adequate error recovery in your code.
For example, stuff like this is dangerous:
FILE* fp = fopen ("C:\\file.dat");
char szLine [256];
fgets (szLine, 255, fp);
fclose (fp);
It's safer to do:
FILE* fp = fopen ("C:\\file.dat");
if (fp == NULL)
displayError();
else {
char szLine [256];
fgets (szLine, 255, fp);
fclose (fp);
}
/ravi
Let's put "civil" back in "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Hi,
Thanks for the reply. I have done as you suggested and added a lot more error checks, and sent the executable out for more testing (hopefully it will at least spew up a more helpful error message that way, thanks for the suggestion). I still don't understand it, though, as I've tested it on a Windows 95 system and it works fine. I can't quite understand why it would work on Windows 95 and Windows Me, but not on Windows 98 - and a couple of Win98 systems have been tested, so it seems that it's not just the user's PC...
Many thanks,
Keith
|
|
|
|
|
Keith, the problem may be with Zip library you're using. Check the vendor's site (assuming it's a commercial product) for release notes regarding Win98.
/ravi
Let's put "civil" back in "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Hi Ravi,
Thanks again for the help. I have now located the problem but haven't figured out how to fix it yet. The problem lies with password encrypted zip files. If the zip files that are extracted aren't password encrypted, they work fine on Win98. If they are, they spew the error. So far I don't know if this has to do with the zip library I'm using (I don't think so, as it is supposed to be compatible with Win98 - it is the one from http://www.artpol-software.com), or with the password encryption I'm using. I'm using cryptography.cpp and cryptography.h, which use the Windows CryptoAPI (got them from Planet Source Code), to encrypt the password and store it in an INI file. The program then reads the encrypted password, converts it and passes it to the Zip...
I doubt posting the code will help as it's very specific (relying on cryptography.cpp and .h and the zlip library from artpol software), but I'll post it just in case. The code I am using is really straight out of the example files (I do a GetPrivateProfileString for Password_str, the default being "NO_PASSWORD_DEFINED"):
//Open the Zip file:
CZipArchive zip;
zip.Open(ZipFile_str);
//If there is a password, decrypt and set it:
if(strcmp(Password_str,"NO_PASSWORD_DEFINED")!=0)
{
//DECRYPT PASSWORD FOR ZIP FILE:
char *sUnencrypted;
clsCryptography MyCrypt;
//Decrypt data:
MyCrypt.bDecryptData(Password_str, "zE76c78cae9opzz231fx" );
// Allocate enough memory to hold unencrypted value
sUnencrypted = new char[MyCrypt.lGetBufferLength() + 1];
// Store unencrypted value in variable
strcpy( sUnencrypted, MyCrypt.sGetBuffer() );
//Pass the decrypted password into the ZIP file:
zip.SetPassword(MyCrypt.sGetBuffer());
delete[] sUnencrypted;
}
Many thanks,
Keith
|
|
|
|
|
According to the documentation, memcpy does not guarantee the result if the source and destination overlap; on the other hand, memmove will graciously handle the case, by coping first the overlapping region.
Consider the following example :
char szTempCpy[] = "this is the most reliable test";
char szTempMov[] = "this is the most reliable test";
memcpy( szTempCpy + 5, szTempCpy, 25);
memmove( szTempMov + 5, szTempMov, 25);
printf("memcpy : %s\nmemmove : %s\n", szTempCpy, szTempMov);
Now, when this is compiled in release you will get the correct behavior : memcpy will trash the data ( the ouput is "this this this this ...") and memmove will get it right ( "this this is the most ...").
The surprise comes when you compile debug : both memcpy and memmove will yield the same result ( the correct one ) - "this this is the most ...". Does anybody have a good explanation for this ?
|
|
|
|
|
the memcpy function has this little bit at the front:
; Check for overlapping buffers:
; If (dst <= src) Or (dst >= src + Count) Then
; Do normal (Upwards) Copy
; Else
; Do Downwards Copy to avoid propagation
mov eax,ecx ;V - eax = byte count...
mov edx,ecx ;U - edx = byte count...
add eax,esi ;V - eax = point past source end
cmp edi,esi ;U - dst <= src ?
jbe short CopyUp ;V - yes, copy toward higher addresses
cmp edi,eax ;U - dst < (src + count) ?
jb CopyDown ;V - yes, copy toward lower addresses
-c
Image tools: ThumbNailer, Bobber, TIFFAssembler
|
|
|
|
|
This protection seems to be implemented only in debug version, and I personally think is a major pain because it lets some easy to catch bugs to creep unobserved. I would expect release and debug versions to be consistent, not to have a different functionality 
|
|
|
|
|
the MSDN does say that you shouldn't use memcpy for overlapping buffers. so, i don't think you can argue that it should work at all in such a situation.
-c
Image tools: ThumbNailer, Bobber, TIFFAssembler
|
|
|
|
|
I perfectly agree - it is not supposed to work at all. I don’t understand why is working. Anyway, if you will take a look at the example in MSDN you'll see that the output is perfect ( compiled debug, I suppose ), even if the note says "MEMCPY.C: Illustrate overlapping copy: memmove, handles it correctly; memcpy does not" 
|
|
|
|
|
There is an article here at code project that says you can print directly to a printer by using fopen("lptN", "w") and writing to the file (just like normal).
I really want to belive this because I have text and HP GL commands in a file that I need to send out to the printer.
I try to fopen("lpt1", "w"); but I get a null pointer back.
I did successfully map a printer to lpt1 (identical to his code except for the \\server\printer) (I don't remove it so I can heck via "net use")
I am in windows 98. Does anyone have any ideas why it's not working?
|
|
|
|
|
Try LPT:. I think (but am not sure) this is mapped to the default printer.
/ravi
Let's put "civil" back in "civilization"
http://www.ravib.com
ravib@ravib.com
|
|
|
|
|
Nope.
PRN doesn't work either.
|
|
|
|
|
Here's another kicker.. opening \\server\printer works, but LPTx doesn't!
|
|
|
|
|
LPT stuff designs a printer connected to the parallel port. I doubt this will work with a USB printer or a network printer.
|
|
|
|
|
I believe the LptN explicityly refers to the physical LPT port. If you have redirected this port then you cannot write to it. This explains why you are able to write data to the UNC name not the physical port name.
|
|
|
|
|
fopen ("lpt1:", "w")
Don't forget the colon.
Sonork 100.11743 Chicken Little
"You're obviously a superstar." - Christian Graus about me - 12 Feb '03
Within you lies the power for good - Use it!
|
|
|
|
|
Does any one know how to fix the drawing of the handle on a floating CToolBar.
Problem: When the handel is drawn only the raised portion is actualy painted the area surrounding it is not.
Trust in the code Luke. Yea right!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
