|
Thanks, Dave buddie!
George
|
|
|
|
|
Heyas all...
I am comming from a Linuc programming background and I'm trying to port a small program to Win32. It's going to be a console app and I have 2 questions on it. Before I go any further I am going to post my program:
#include "iostream.h"
int main(void){
int i;
cout<<"\n\t\t CoxEdgeLauncher Version .98\n";
cout<<"\t\t(c)2003 Digitally Khaotic Solutions, Inc.\n";
cout<<"\nInitializing CoxEdge";
for(i=0;i<5;i++){
cout<<"."<<flush;
sleep(1)
}
cout<<"\nCalibrating delay loop";
for(i=0;i<6;i++){
cout<<"."<<flush;
sleep(1);
}
cout<<"\nLaunching CoxEdge..."<<flush;
sleep(3);
cout<<"\n\n***App Started. This line and DOS box will disappear***\n\n";
return(1);
}
Now, I know I'm missing some headers in there and that's my first question. What header would include a sleep or sleep like function in Win32? On my Linux box I'd use unistd.h but it doesn't seem to exist on Windows. The second question is, how do I call an external program from within my code? i.e. I want notepad to startup right after "Launching CoxEdge..." is displayed.
I'd appreciate any info anyone can provide for me.
Thanks in advance.
Digital Khaos
"Diplomacy is dead. Feel my wrath!"
|
|
|
|
|
You want Sleep() with a capital S. It lives in windows.h
system() should be enough to launch Notepad. Otherwise look at ShellExecute().
Software is everything. It also sucks. Charles Fishman [^]
Awasu 1.0.3 (beta)[^]: A free RSS reader with support for Code Project.
|
|
|
|
|
Taka I appreciate the quick response. The Sleep() function is working prefectly thank you. I am having a bit of a time trying to figure out ShellExecute() though. I have the following:
ShellExecute(NULL, "open", "c:\windows\notepad", NULL, NULL, SW_SHOWNORMAL);
Now, if I make it:
ShellExecute(NULL, "open", "notepad", NULL, NULL, SW_SHOWNORMAL);
It works. I guess my question is how do I specify a path? For the final outcome the path to the program is "s:\CoxEdge\coxedge.exe". When I put in full paths, I get warnings aluding to unrecognized escape characters.
Any thoughts?
Again I appreciate it.
Digital Khaos
"Diplomacy is dead. Feel my wrath!"
|
|
|
|
|
the slashes in your string are being interpreted as escape characters \w and \n respectively.
use \\ to escape slash characters i.e. "c:\\windows\\notepad"
Software is everything. It also sucks. Charles Fishman [^]
Awasu 1.0.3 (beta)[^]: A free RSS reader with support for Code Project.
|
|
|
|
|
Welcome to Windows, John. 
Two points - the argument to Sleep() is milliseconds. I assume you mean to sleep for 1 second, so use Sleep(1000).
Second, check out the VC forum FAQ[^] which includes a FAQ on launching other programs.
--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
|
|
|
|
|
Since you are building a console application you should use the function:
#include <process.h>
or
#include <stdlib.h>
int system( const char *command );
And if you really insist on using something else, and you don't understand ShellExecute, then go with
WinExec( "Application.exe", SW_SHOW );
// Afterall I realized that even my comment lines have bugs
|
|
|
|
|
I have a class ...
<br />
<br />
class blah {<br />
...<br />
public:<br />
...<br />
double buffer[100][100];<br />
...<br />
};<br />
Now in another class I do this ...
<br />
<br />
anotherClass::anotherClass () {<br />
...<br />
for( int i=0; i<100; i++ ) {<br />
for( int j=0; j<100; j++ ) {<br />
p2_blah->buffer[i][j] = (double)5.1234;<br />
}}<br />
... <br />
}<br />
<br />
void anotherClass::doSomethingWithBuff( doube **b, int x, int y ) {<br />
...<br />
if ( z <= b[x][y] ) {
b[x][y] = z;
}<br />
}<br />
... the b[x][y] is causing my program to crash 
What should I be doing instead?
I can't figure out how to prototype doSomethingWithBuff with double[][] instead of
double** or even if I should?
|
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
