|
Hey Guys
Can anyone tell me what this message means "ASN1 Unexpected end of file"
and this is produced by the CryptVerifyDetachedMessageSignature
Cheers
Peter
|
|
|
|
|
Hey all!
I recently stumbled upon a REALLY WEIRD bug - and I'm totally stuck!
Bug description: I send EM_GETTEXTEX message to a rich edit control, and get an empty string - even though there is definitely a string there - it even returns the correct length of the string when I send an EM_GETTEXTLENGTHEX message!
I compile the code in 4 modes:
1. Deubg build, an EXE application
2. Debug build, an ActiveX application
3. Release build, an EXE application
4. Release build, an ActiveX application.
I compiled using both VC++ 7 and VC++ 6 (no SP), and used Windows 2000 (no SP) + IE6 for the ActiveX.
I was also able to occasionally reproduce the bug in a Debug build when I used NuMega BoundsChecker.
And here is the weirdest part:
I have some code that looks more or less like this:
1. Get string from Rich Edit control and display it
2. Get string from Rich Edit control and display it
3. char *sz = new char [1]
Now, in the ActiveX Release build - the previous code displayed two empty strings. When I removed line 3 - the code worked. Or maybe it was the other way around... But anyway, that was the situation.
I thought about subclassing the Rich Edit control, causing the program to crash when the EM_GETTEXTEX message is received, and then follow the Rich Edit Control assembly code and see what's going inside there - but it seems too painful!
Does anyone have any constructive idea?? (other than "go drink your troubles away", please)
Thanks!
|
|
|
|
|
Tomasz was nice enough to tell me where the data for the Summary page resided. Can someone tell me direct me to some code that manipulates it?
"Where in the world is the data persisted?
If you're using W2K, it's stored in a 'Document Summary Info' stream. Alternate file streams are a NTFS-only feature. Write something at a 'Summary' page, then drag the file to A: - you'll see the warning about data loss; only the main stream will be copied to floppy.
Tomasz Sowinski -- http://www.shooltz.com"
|
|
|
|
|
Can someone tell me direct me to some code that manipulates it?
I swear I saw mention of using streams in a recent MSDN mag, like maybe 2 or 3 issues ago. Basically, when opening the file, you add a colon and the stream name to the end of the path, for example "D:\readme.exe:STREAMNAME".
Where in the world is the data persisted?
In the file system. 
--Mike--
http://home.inreach.com/mdunn/
Trillian: What are you supposed to do with a manically depressed robot?
Marvin: You think you've got problems. What are you supposed to do if you are a manically depressed robot?
|
|
|
|
|
I created DLL that contain a class for using by clients.
And it is right.
But my clients say they can't use with this class because they works in Delphi and impossible create object from my class in it.
-----------------------------------------------------------
I want to know :
Is it right ?
How can I to create in my DLL global function that will create object from the class in this DLL and will use its member functions
for clients.
----------------------------------------------
This func have to get some parametrs from the clients and to return parameter. as so:
BYTE* func(int a, char* str)
{
CMyClass obj;
..............
..............
if ( obj.DoModal()== 0)
return ----
return ------------
} 
-------------------------------------------
My project is in: MFC AppWizard (dll) -> MFC Extension DLL
Please Help me !!!!!
Gil
|
|
|
|
|
in general, only MFC clients can use MFC extension DLLs.
if you want to export functions to non-MFC clients, you will need to use plain C interfaces on all of your exported functions.
-c
------------------------------
Smaller Animals Software, Inc.
http://www.smalleranimals.com
|
|
|
|
|
I inserted my this project to regular dll by the wizard.
I have a dialog class and I writed export global function so:
/********************************************************/
extern "C" __declspec(dllexport) int func()
{
AFX_MANAGE_STATE(AfxGetStaticModuleState());
MyDialog dlg;
dlg.DoModal();
return dlg.num;
}
/********************************************************/
But when I test it with client program it dont show me the dialog.
It is only return me the return value.
 WHY ???
Gil
|
|
|
|
|
Have you debugged into the DLL and found which line it is failing on. It's probably failing somewhere in the InitDialog code. You'll need to debug it to find out what the problem is.
However, I recommend that you try and implement it as a COM object, Delphi should have no problem with a COM object.
Michael
|
|
|
|
|
May be this is an easy question, however i did not find so far an easy answer.
How can I hide the menu in an application
|
|
|
|
|
Use SetMenu() with a NULL handle
AfxGetMainWindow()->SetMenu( NULL );
|
|
|
|
|
Hi,
I've added CMemDC class to my project, and it has a memory
leak somewhere that I can't locate.
I need 2 DC's that stay in memory for the life of the
application, however, I'd rather not have them constantly
created inside the OnPaint() function, since I have some
intensive calculations done to them.
Can I get some suggestions on correct methods of initializing
my CMemDC. My app is Dialog based, and I've been using
different methods to initialize them inside my OnInitDialog()
function.
Also, is it bad form to use the 'new' operator on CMemDC,
considering I didn't see it defined within the class?
Best Regards,
-t
|
|
|
|
|
If you could get the dialog to use a window class that you register yourself that had the CS_OWNDC style bit set, you could move the CDC::CreateCompatibleDC stuff out of OnPaint. In a standard MFC dialog based app, DoModal uses CreateDialogIndirect to create the dialog - if you override DoModal and get it to use a DLGTEMPLATEEX structure I think you could supply your own window class.
I use this CS_OWNDC trick in my Gribble2 article, but haven't tried it for a dialog.
|
|
|
|
|
I'm unclear on the necessity of having to register the class
with CS_OWNDC.
Can't I initalize a couple CDC's, keep them in memory,
and blt them to the screenDC (aka my Dialog Client area),
but then do whatever calculations I need when they need to be
updated.
I apologize ahead of time if I missed your explaination in your
articles.
Much Thx,
t²
|
|
|
|
|
I guess you can, but you mentioned the CMemDC sample which I saw doing a lot of this stuff in OnPaint, and, in the heady rush of feeling I actually had something to say...
My feeling was that you we're looking to optimize as well as reduce code in OnPaint, and a window with its own DC can do both, although the real bottlneck with blitting seems to be the overall size of the bounding rectangle of the clipping region.
But I think your right, the CS_OWNDC is not a prerequisite for eliminating the CreateCompatibleDC code in OnPaint - does 'feel' a bit safer, though.
later
Oh - and I'm assuming that the size of your dialog doesn't change - that would be a good reason to leave the mem dc setup in OnPaint.
Um - what is it exactly you are going to draw on the mem dc?
|
|
|
|
|
My project will be an extension of a prewritten custom
ATA HardDrive debugger. Object to display errors at different
block locations on the platter. So there could be potentially
20000x20000 locations (roughly) that I need to map.
I've been experimenting on a much smaller scale, but have
run into a memory leak. I'm not MFC trained (nor even Comp. Sci
trained), so my methodologies could be all out of wack.
Dealing with such a large "map", I've been looking for a way
to do a one time calculation for a full summary view of the map,
then calculate smaller chunks when I need a zoomed view.
Very vague explaination, I know...sorry.
And yes my Dialog doesn't change (for now it's 800x600).
-t²
|
|
|
|
|
Ah, well, lets go back to the leak then.
If you're using a typical MFC dialog based app, make a note of the allocation number of the leak from the object dump.
Start the program again with F10. Open the watch window, and enter this variable name:
{,,msvcrtd.dll}*__p__crtBreakAlloc()
If it shows a -1, you're in luck. Enter the value of the allocation that leaked, and the program will break when its allocated - and you can just hop up the call stack to see whats leaking.
Basically, if you use new you need to use delete to free the memory allocated - but sometimes its tricky to determine where the leak occurred.
Note that sometimes {,,msvcrtd.dll}*__p__crtBreakAlloc() doesn't show up - _ctrBreakAlloc may work.
The allocation number of the dump is the one in curly braces in an output like this:
E:\Develop(Tim)\OPCSim1\OPCSim1.cpp(51) : {64} normal block at 0x00300030, 1 bytes long.
Data: < > CD
|
|
|
|
|
Excuse my ignorance, how can I get the allocation number,
and where do I input it?
I did look at "{,,msvcrtd.dll}*__p__crtBreakAlloc()", and
it did come up -1.
On a separate note, if I declare a GDIObject, say...
CBrush testBrush;
Should I explicitly delete it when I'm done with the object?
(Given that I did save the original CBrush and restored it
to the CDC when I was finished. More specifically, I'm using
SaveDC and RestoreDC)
If I don't delete the object, do GDIObjects have their own "safe"
destructors?
Regards,
-t²
|
|
|
|
|
Oh - ok - I make a distiction between resource leaks and memory leaks - perhaps what you have is a resource leak.
If you are working with classes derived from CGdiObject (like CBrush, CPen) the ~CGdiObject destructor should free the resource for you - so when the testBrush goes out of scope, or its containing class is destroyed, you should be ok. MFC will ASSERT in debug mode if you try to call CreateBrush or CreatePen twice without calling DeleteObject.
If you are working with handles returned from say, a call to ::CreateBrushIndirect (not using CBrush) you must be careful to destroy the object (after deselecting it from the DC).
What is telling you that you have the leak? - I thought it was a dump provided by the debug C runtime allocation routines - in which case the allocation number would be the one in curly braces.
Say - since this thread is getting kind of buried now, why don't you post a bit of code (showing your SaveDC and RestoreDC calls and stuff that you are doing in between) in a new thread - rem - use <pre> and </pre> to surround your code - if its a resource leak, it may not be obvious - I seem to recall some subtle gotchas that have appeared in these posts - but I bet you'll get a helpful answer real quick.
|
|
|
|
|
I placed a followup on our discussion in a new thread...
"CDC Resource/Memor Leaks... (continued)..."
-t²
|
|
|
|
|
I have several static controls that are mapped to CString member variables.. I have a clear function that sets all the CString member variables to "".. When I execute "OnClear" all my edit boxes and combo boxes clear but my static controls do not clear unless I minimize then maximize the dialog box. Any ideas on how I can repaint the dialog box to reflect the new values.. I do a UpdateData(FALSE) at the end of my clear function.
Thanks,
Rob
|
|
|
|
|
Call RedrawWindow() on your dialog to make it repaint.
--Mike--
http://home.inreach.com/mdunn/
Trillian: What are you supposed to do with a manically depressed robot?
Marvin: You think you've got problems. What are you supposed to do if you are a manically depressed robot?
|
|
|
|
|
Hello, the codegurus around the world.;)
Try to SetWindowText() to update the text for Static control.
Have a nice day!
-Masaaki Onishi-
|
|
|
|
|
I have tried both methods and neither are working. It may be because the background of my dialog is a bitmap. I have opened spy++ and am trying to find the function that they use to redraw the whole dialog when I go from minimized to maximize.. The RedrawWindow() may be the ticket, as of right now I have only tried RedrawWindow() with out any parameters. I’ll play around with it to see if I can get it to work.
Thank you both for your responses.
Rob
|
|
|
|
|
Never mind the last reply.. RedrawWindow() works fine.. I was calling UpdateData(FALSE); after the RedrawWindow()..
Everything is working great!!
Thanks!
Rob
|
|
|
|
|
Please, check your DoDataExchange() function,
It may look like this
void CDlgStatic::DoDataExchange(CDataExchange* pDX)
{
CDialog::DoDataExchange(pDX);
//{{AFX_DATA_MAP(CDlgStatic)
DDX_Text(pDX, IDC_STATIC_1, m_Static);
...........
//}}AFX_DATA_MAP
}
In general, there is no need to repaint the control.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
