|
Watertreader wrote:
I am inserting an external control into the code... does it has to be initialised?...
Yes. ActiveX controls must exist and be registered on the target machine.
Watertreader wrote:
the error messge disappear when I use in the RElease mode instead of debug mode
Compare the compiler/linker options between the two builds. You can do this through the IDE but I find it easier to open the project's .dsp file instead.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
DavidCrow wrote:
Compare the compiler/linker options between the two builds. You can do this through the IDE but I find it easier to open the project's .dsp file instead.
That shouldn't matter when it comes to COM DLLs, as the only memory shared between the DLL and any other DLL/EXE should be owned by the COM heap, and not the individual DLL/EXE.
But maybe MFC is doing sneaky things behind the back, I wouldn't know. I ditched MFC a long time ago. 
--
Schni Schna Schnappi! Schnappi Schnappi Schnapp!
|
|
|
|
|
Jörgen Sigvardsson wrote:
That shouldn't matter...
It most certainly does matter. Whether an application is a DLL, EXE, COM or otherwise, if you have different settings other than those that are supposed to be there for the RELEASE and DEBUG builds, you can expect to see differences.
Jörgen Sigvardsson wrote:
...when it comes to COM DLLs, as the only memory shared between the DLL and any other DLL/EXE should be owned by the COM heap, and not the individual DLL/EXE.
I'm not sure what this has to do with checking compiler/linker options.
In the end, this may not even be the problem but it is a possibility that is easy to eliminate.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
DavidCrow wrote:
Whether an application is a DLL, EXE, COM or otherwise, if you have different settings other than those that are supposed to be there for the RELEASE and DEBUG builds, you can expect to see differences.
Only if you're linking statically because...
DavidCrow wrote:
I'm not sure what this has to do with checking compiler/linker options.
IIRC, DLLs get their own heaps, while LIBs don't. I think there's an entry about this on Raymond Chen's blog. I reserve the right to be incorrect.
DavidCrow wrote:
In the end, this may not even be the problem but it is a possibility that is easy to eliminate.
Link errors are easy to find. It's worse when you allocate memory in a DLL, and you free it in another module. The runtime errors are not obvious, as I witnessed last week when my app loaded the wrong DLL. :gah:
--
Schni Schna Schnappi! Schnappi Schnappi Schnapp!
|
|
|
|
|
Jörgen Sigvardsson wrote:
Only if you're linking statically because...
What does linking statically have to do with the subject matter? Go back and re-read this thread. The OP stated that he was seeing differences in his program when going from a RELEASE build to a DEBUG build. My suggestion was to check the compiler/linker options to make sure they are the same. It's very easy to add an option (e.g., /Gr vs. /Gz, or /Zp4 vs. /Zp8) to one and forget to add it to the other.
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
Perhaps I might be using or linking the lib and dll in a incorrect manner.. but it does not seem to affect the running of the program though....
|
|
|
|
|
When I put JNI code below into a DLL that is called by a VB application, the application gives error message: "Error 5 calling validation routine: Invalid procedure call or argument Do you wish to try again ?". It is OK to have the JNI code in an C++ application.
Is there a way to fix the problem and how ?
// using namespace std; // without this, string type will not be recognized
std::string className = "com/hewitt/imaging/inputaccel/IDLookup";
options[0].optionString = "-Djava.class.path=%CLASSPATH%;./IDLookup.jar";
memset(&vm_args, 0, sizeof(vm_args));
vm_args.version = JNI_VERSION_1_2;
vm_args.nOptions = 1;
vm_args.options = options;
status = JNI_CreateJavaVM(&jvm, (void**)&env, &vm_args);
...................
Thanks very much for advice
XSN
|
|
|
|
|
I have a rectangle representing a particular area of the screen.
I want anything within this rectangle to get repainted.
It would be nice if I did not have to invalidate the enire screen.
InvalidateRect(NULL, NULL, FALSE) invalidates the entire screen.
It seems that InvalidateRect(NULL, &TheRect, FALSE) also invalidates the entire screen.
Please suggest something that only invalidates a part of the screen.
|
|
|
|
|
Blake Miller wrote:
It seems that InvalidateRect(NULL, &TheRect, FALSE) also invalidates the entire screen.
Only if TheRect encompases the entire screen. In other words, if TheRect had the following properties, the entire screen would indeed be repainted:
TheRect.left = 0;
TheRect.top = 0;
TheRect.right = 1023;
TheRect.bottomn = 767;
"Ideas are a dime a dozen. People who put them into action are priceless." - Unknown
|
|
|
|
|
What was strange about my initial observation was that I had an area of the screen represented by my rectangle. This was only on the desktop window. No other windows touched this rectangle. When I invalidated that rectangle, the windows completely beside that rectangle also repainted. That is why I concluded that any invalidation of an area of the 'screen' would cause all windows to repaint.
|
|
|
|
|
See SelectClipRgn(). I believe Windows will restrict painting to the selected region when a WM_PAINT is processed.
/ravi
My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
I am figuring by the time I calculate all the windows possibly affected, get their DC, set clip regions, invalidate clip regions, etc. I might as well repaint the entire screen?
I only have a rectangle covering 'part' of the entire screen. I don't know all the windows that are necessarily touching this rectangle.
I tried invalidating the area of the desktop window, but other windows on TOP of the desktop window in that same area would not necessarily repaint.
Then I used WindowFromPoint on the four corners, and invalidated the area of each window where the rectangle was located, but that would not necessarily erase the caption areas, menus, or other toolbars and such in those same windows.
I suppose I could get the DC of each of these windows and see if the clipping functions will help or not. Most of the invalidation documentation always refers to the 'client area' of the widnow, and I have found very little referring to the 'non-client area'.
|
|
|
|
|
Actually, all you need is the DC of the desktop window. Compute the invalid rect (you already have this), create a rectangular clip region and select it into the desktop's DC, then invalidate the desktop (and optionally force an immediate repaint by calling UpdateWindow()).
I hope what I've suggested isn't overkill.
/ravi
My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
No it is not overkill.
This is what I have so far, and still no result. Am I missing something?
HWND hWndDesktop = ::GetDesktopWindow();<br />
HDC hDcDesktop = ::GetDC(hWndDesktop);<br />
<br />
int nX = BOUND(m_ptZoom.x, m_nxZoomed / 2, m_nxScreenMax - (m_nxZoomed / 2));<br />
int nY = BOUND(m_ptZoom.y, m_nyZoomed / 2, m_nyScreenMax - (m_nyZoomed / 2));<br />
<br />
RECT rBounding, rErase;<br />
rBounding.left = nX - m_nxZoomed / 2;<br />
rBounding.top = nY - m_nyZoomed / 2;<br />
rBounding.right = rBounding.left + m_nxZoomed;<br />
rBounding.bottom = rBounding.top + m_nyZoomed;<br />
::InflateRect(&rBounding, 1, 1);<br />
<br />
::CopyRect(&rErase, &rBounding);<br />
::MapWindowPoints(NULL, hWndDesktop, (LPPOINT)&rErase, 2);<br />
HRGN hRegion = ::CreateRectRgn(rErase.left, rErase.top, rErase.right, rErase.bottom);<br />
::InvalidateRgn(hWndDesktop, hRegion, TRUE);<br />
::UpdateWindow(hWndDesktop);<br />
<br />
::DeleteObject(hRegion);<br />
::ReleaseDC(hWndDesktop, hDcDesktop);<br />
|
|
|
|
|
InvalidateRgn() adds the specified region to the existing invalid area. Selecting it into the desktop window's DC using CDC::SelectClipRgn() will replace (i.e. redefine) the invalid area. I think this is what you want to do. (Fingers crossed).
/ravi
My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
 Not that either.
|
|
|
|
|
Just for grins, can you TRACE() the value of rErase and ensure it's not the size of the desktop?
/ravi
My new year's resolution: 2048 x 1536
Home | Articles | Freeware | Music
ravib@ravib.com
|
|
|
|
|
I had previously tested the coordinates and they are not size of screen.
They are something like L=317,R=450,T=400,B=550 but nothing NEAR the size of the screen.
With the invalidate region code, I have not been able to get anything to erase, whether my rect was drawn on the desktop window or onto an application window.
Thansk for your help. It is probably some simple API or combination of them we are both failing to realize.
I would think this is possible, without lengthy enumeration of windows on the desktop, descending into children, etc.
Worst case scenario, I invalidate entire screen. I already know that works.
|
|
|
|
|
Do you have a dual screen setup? Sometimes when I have the SQL Enterprise manager open at the same time as VS.NET, they get caught up in an "invalidation race". VS.NET invaldates something that triggers a total repaint. This in turn triggers the enterprise manager to do a total repaint, which in turn triggers VS.NET ad infinitum. Sometimes it just won't stop until I minimize either one of them. Freaky!
--
Schni Schna Schnappi! Schnappi Schnappi Schnapp!
|
|
|
|
|
No recursion here.
Just a single massive repaint of entire screen seems to work so far. I am trying to avoid that.
When I try the clipping, regions, etc. as suggested sto this point, NO repainting occurs reliably all the time. Bits and pieces of windows will repaint, but not all necessary areas 
|
|
|
|
|
Did you notice this documentation for the hWnd parameter:
hWnd
[in] Handle to the window whose update region has changed. If this parameter is NULL, the
system invalidates and redraws all windows, and sends the WM_ERASEBKGND and WM_NCPAINT
messages to the window procedure before the function returns.
Is it the desktop window (i.e, the "background") you wish to redraw, or every visible window within an area?
If you intend to redraw the desktop window, I suggest you get a handle to the desktop window by calling GetDesktopWindow(), and then invalidate that window.
--
Schni Schna Schnappi! Schnappi Schnappi Schnapp!
|
|
|
|
|
Thanks for the note and suggestions.
Every visible window containing parts of its area within a specified area of the screen.
Speficially, only to invalidate the area of every window visible within the specific area. For exmaple, if I am in the middle of a window, it should not have to repaint is frame.
The combinations of what parts of which windows might be affected, given that I only have a rectangle representing a part of the screen, makes the effort almost more trouble than just telling the entire screen to repaint.
|
|
|
|
|
I'm sorry I cannot be of any assistance.
I must say that what you are doing sounds quite intriguing. What kind of software are you writing?
--
An eye for an eye will only make the world blind.
|
|
|
|
|
A feature-rich ugrade to the aging ZoomIn utility.
Do you have any suggestions for features you would like to see in it?
My starting point came from here
http://www.csc.calpoly.edu/~bfriesen/software/zoomin.shtml[^]
When you left-click on the ZoomIn window, you drag a 'outline' rectangle to another part of the screen, that is what you will view.
In most cases, a DSTINVERT PatBlt will draw/erase this rectangle. In other cases, though, I only know where it might have been drawn and not which combination of PatBlt will get the rectangle erased, so I am looking to tell the 'owner(s)' of that screen real estate that the area must be repainted. Trying to invalidate an 'area' of the screen is what is so problematic.
::InvalidateRect(NULL, NULL, FALSE);
works every time, but it causes the ENTIRE screen to repaint.
I could probably come up with a combination of EnumWindows/GetWindowRect/ScreenToCLient/IntersectRect/Invalidate loops that would get the job done, but then is that much faster or efficient than just telling Windows to invalidate the entire screen?
I might do that as an exercise and then profile it just for kicks.
I was hoping some graphics wizard might point me to the magical GDI API I was overlooking. There might not be one, though
|
|
|
|
|
As I do a lot of GUI work, this is the kind of tool that I would use extensively. Features that I'd want in such software are:
* Pixel color values in both decimal and hexadecimal
* Coordinate display in both client coordinates and screen coordinates
* Grid and no grid
* Non-restricted zoom in level, and not just x2, x4, x8 like some tools insist
* Saving capabilities in case one wants to compare visual changes with earlier renderings
As for the problem at hand, EnumWindows is probably a good solution. I don't think it'll degrade performance so much that it's noticable. But I agree, it's a shame that InvalidateRect doesn't work as one would expect.
Please let me know if you need bug testing etc. Is this an open source, free tool, or shareware project? If it's free, then please sign me up for a copy once it's passed Q&A!
--
An eye for an eye will only make the world blind.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
