|
|
DOH!
Nope I didn't try that! Thanks that did the trick.
Here's what I did try 
<br />
void anotherClass::doSomething( double [100][100] b ...<br />
I was thinking that "double [100][100]" was a type!
|
|
|
|
|
Are you sure that:
1) b is valid - i.e. you aren't passing in null, or some garbage.
2) x and y are valid (i.e. in this case both are >= 0 and < 100)?
There is no problem passing in the array as a double** as long as you don't try and access past the end of it.
Dave
http://www.cloudsofheaven.org
|
|
|
|
|
That breaks because an array and a pointer are equivalent only for one-dimensional arrays. It's hard to explain in words, but the syntax b[x][y] breaks because b is declared as a double**, that is, pointer to double*, when that is not how the underlying data is stored.
--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
|
|
|
|
|
Using VC7/MFC I have a dialog app that has a seperate thread to handle animation. How can I do a lock so that I can update a back buffer(double-buffering) between the main thread and the graphics thread. When I try to lock in the main dialog it freezes which I think is being caused by
the message pump being stopped by the lock in the thread. Any ideas as to the proper (and hopefully easy) way to handle multi-thread screen updating? Thanks
|
|
|
|
|
One more thing...is MsgWaitForMultipleObjects the proper way to do this?
|
|
|
|
|
Off the top of my head, put a critical section in both the back buffer drawing routines and the main drawing routine.
Another common method is to create two back buffers and ping pong between them using a BYTE index (which is always atomic) to indicate which buffer is active for painting in the foreground and drawing in the background.
|
|
|
|
|
Tried the critical section but when it tries to lock in the main thread, everything hangs for some reason. I think the message pump may be getting blocked. Used critical sections a lot in my server code and they work great. For some reason it doesn't seem to want to cooperate with graphics routines.
|
|
|
|
|
I'm going to guess you have one path in the thread which doesn't release the critical section.
If that doesn't work, try running around your office screaming and waving your arms in the air.
|
|
|
|
|
lol tried both. The screaming worked better than the critical section. I checked all the paths, only use it in one place in each thread. Had that happen before so it was the first thing I thought to check. Very perplexing problem.
|
|
|
|
|
Yes, but was it a manly scream or a high-pitched girly scream? I've found that only high-pitched girly screams help with threading problems.
Seriously though. Could you post some of your code?
Software Zen: delete this;
|
|
|
|
|
Messages for a window can be processed only by the thread that created the window. That's how message pumps work. Designing you code so that another thread updates the UI will likely result in other problems (or at the very least, inefficiencies when the threads have to wait on each other).
But sticking with your question, if the worker thread is the only one touching the back buffer, why do you need a lock at all?
--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
|
|
|
|
|
Thanks for the info. The back buffer is processed by the paint routine in the main thread as well. What's the best way to handle multi-threaded graphics to a dialog window?
|
|
|
|
|
Maybe I can explain it better. Only the main thread that created the dialog processes messages. The worker thread only updates only the back buffer which is then processed by the main thread and updated to the screen.
|
|
|
|
|
Hi all,
I've created a release version of an application which uses MFC and when deployed on my test machine I get the error:
"The dynamic link library MSVC60.dll could not be found in the specified path ...."
I know what the error means, but why in the heck is it looking for this file? I thought the release build was independent of the Visual Studio dlls. What do I need to do in order to correct this problem?
|
|
|
|
|
will1383 wrote:
I thought the release build was independent of the Visual Studio dll
only if you build with static linking. (Project / Settings / General - in VC6)
-c
Image tools: ThumbNailer, Bobber, TIFFAssembler
|
|
|
|
|
What's really strange though is that I've been using dynamic linking all along, and have had no problems what-so-ever.
Strange. I'll try a static build for kicks.
|
|
|
|
|
The debug DLL (MSVC60D.DLL) may be installed but not the non-debug DLL.
|
|
|
|
|
use the visual studio installer, and include msvc60 as a merge module, that should solve your problem right there.
hey
|
|
|
|
|
I'm writing a program that gets a computer name from a list of IP address. The first time thru it gets the computer name without a hitch. From then on I keep getting a error.
Here is a snippet of my code that does the gethostbyaddr.
}<br />
LPHOSTENT lphp;<br />
struct in_addr in_addrIP;<br />
<br />
<br />
<br />
if (!InitSocket()) <br />
{<br />
AfxMessageBox("Error initializing WSAStartup", MB_OK | MB_ICONSTOP);<br />
return -1;<br />
}<br />
<br />
in_addrIP.S_un.S_addr = inet_addr(szAddress);<br />
lphp = gethostbyaddr((char FAR *)&in_addrIP, sizeof(struct in_addr), PF_INET);<br />
<br />
if (lphp == NULL)<br />
{<br />
AfxMessageBox("Failed at gethostbyaddr", MB_OK | MB_ICONSTOP);<br />
return -1;<br />
}<br />
<br />
WSACleanup();<br />
<br />
return lphp->h_name;<br />
<br />
<br />
}
Am I supposed to initialize something before I give it another address to try?
Thanks
Tom Wright
tawright915@yahoo.com
|
|
|
|
|
Yes, you must reinitialize winsock after WSACleanup().
Kuphryn
|
|
|
|
|
I am. Each time I drop into this fuction it runs the InitSocket().
Tom Wright
tawright915@yahoo.com
|
|
|
|
|
Which does what? The counterpart to WSACleanup() is WSAStartup(). If your "convert" function is being called multiple times, I'd move the calls to WSACleanup() and WSAStartup() so they are only called once.
|
|
|
|
|
Understandable. I'll try that. Although that should not make a difference since each time I come out of this function I clean up the socket. And each time I come into it with a new ip address, it's initialized.
There may be some resouce overhead with doing it this way which is why I may take up your suggestion and move it out of this function and only do it once, but this still does not fix my problem.
Any other suggestions?
Thanks
Tom Wright
tawright915@yahoo.com
|
|
|
|
|
Tom Wright wrote:
Any other suggestions?
Not without knowing what InitSocket() does. If it calls WSAStartup(), which might be failing, what does WSAGetLastError() return?
In your original post, you state that "From then on I keep getting a error." but give no indication as to the error or the line causing it.
inet_addr() can return INADDR_NONE but there is no check for that.
gethostbyaddr() can return any number of errors, but none are being checked for. Call WSAGetLastError() to find out.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
