|
Hi, I'm developping a gui for a command based application and I need to launch and terminate that command based program. The gui runs on a windows platform and the command-based program runs in unix platforms and also in windows (there are 2 versions). I also need the ability of copying and retrieving files (also retrieve file properties such as size and time, etc).
So the question is simple:
Which technology should I use in my gui to "communicate" (launch/kill) with that multiplatform command-based program? Should I use RPC or there's another technology better for this specific case?
Thanks in advance.
|
|
|
|
|
xatanu wrote:
Which technology should I use in my gui to "communicate" (launch/kill) with that multiplatform command-based program?
If it (i.e., the command based application) resides on a machine separate from the GUI machine, check out RPC.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Thank you very much for your fast answer.
The problem is when the command based app resides on a different machine: i'll check RPC.
When it resides on the same machine i think it's quite simple using ShellExecute.
Can you advise me some documentation about RPC that could help me?
I think there's an easier method: using rsh (remote shell) commands for launching and retrieving files, but then it's not possible to kill the processes. What do you think about this method?
Greets
|
|
|
|
|
Alright you guru's. I have a question for ya. I have a test application that at first I set all the GDI objects (boxes, Rich Edit control, and lines) using the MM_TEXT (display locations). I found out what a logical inch was (Using MM_TWIPS at 1440x1440) and converted that to display for the current display and printer. On my main system the conversion from LPtoDP returned 102x108 and for the printer 1201x1204. When I copied the application to a different OS (using VMWARE), with the resolution set to 1024x768 and doing the same thing, it returned either 81x81 (or 96x96) and the printer varried by 1 or 2 (probably due to rounding). When I would print using the display locations, I wanted the boxes to be 1inch x 3inch and 1inch x 7 inches. The print outs as I expected were not 1x3 or 1x7 or even close. Using the Logical units they were pretty close!
Next I tried switching all the values to TWIPS and then converting the TWIPS to display units to create the controls. On my main system, it looked darn good. On the VMWARE Os, the output looked different.
What I need is several fold.
- Am I correct in saving the logical (TWIPS) values and using LPtoDP to convert to display units to create the controls?
- Is my assmption correct in saying that 1440x1440 converting to LPtoDP gives the correct DPI for one inch the way the display is configured?
- What are the traps that I maybe falling into and how do I avoid them. Device independent drawing.
Thanks
Larry J. Siddens
Cornerstone Communications
TAME THE DOCUMENT MONSTER
www.unifier.biz
|
|
|
|
|
HUMMM, I maybe assuming something that is not correct!
The code to calculate the LPtoDP is as follows:
Lx = Logical x direction
WOx = Window Org x direction
VOx = Viewport Org x direction
WEx = Window Extent x direction
VEx = Viewport Extent x direction
Dx = Device Unit x direction
Dx = ( Lx - WOx ) * VEx / WEx + VOx
So, with this knowledge in a 1280x1024 resolution screen the values are as follows:
Dx = ( 1440 - 0 ) * 1280 / 18142 + 0
Dx = 101.598501 and rounded up to 102.
When this same calculation is done on a 1024x768 screen the value rounded come out to be 81.
So, the question is how do I get the text (rich edit... starting to hate these things!) that was created in a 1024x768 res screen like it did when it was created in a 1280x1024?
Do I come up with some puzzles or what?
Thanks if you can answer. I really guess I don't quite understand!
Larry J. Siddens
Cornerstone Communications
TAME THE DOCUMENT MONSTER
www.unifier.biz
|
|
|
|
|
I want to do something like "Print Screen" button do. when you press this button you can capture what ever is visible on the monitor as an image. How can I do it.I want to take some parts in the screen but I guess functionality is the same as getting all the screen.
Mazy
No sig. available now.
|
|
|
|
|
I don't complete understand your question as the Print Screen button does exactly what you are after (i.e., it captures the entire screen or the active window) and copies it as an image into the clipboard buffer.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
DavidCrow wrote:
what you are after (i.e., it captures the entire screen or the active window) and copies it as an image into the clipboard buffer.
Yes,how does it capture the screen?
Mazy
No sig. available now.
|
|
|
|
|
I don't know. Something built into the keyboard driver I suppose.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Hi
I have a dialog which is pretty big. When resolution '1024*768' is used, no problem. But when '800*600' is used, i can't see the entire dialog.
Is there anyway to have scrollbars on it? I've put some scrollbars on it, but it doesn't seem to work :S
|
|
|
|
|
you need to embed the scrollable part of a dialog inside the main dialog.
have a look at :
http://www.codeproject.com/dialog/scrollablechilddialog.asp[^]
Maximilien Lincourt
"Never underestimate the bandwidth of a station wagon filled with backup tapes." ("Computer Networks" by Andrew S Tannenbaum )
|
|
|
|
|
You may want to evaluate why the dialog box is so large. Perhaps you just have too many things going on in there at once, which could be better split up into individual tabs (property sheets).
Regards,
Alvaro
Hey! It compiles! Ship it.
|
|
|
|
|
ok thanks for the fast reply's
i'll accept maxilien as best answer
Catch you guys later on
|
|
|
|
|
i personally think alvaro's answer the best but its ur call as to the situation
"there is no spoon"
biz stuff about me
|
|
|
|
|
I too have the same opinion.
"A robust program is resistant to errors -- it either works correctly, or it does not work at all; whereas a fault tolerant program must actually recover from errors."
|
|
|
|
|
agreed.
Maximilien Lincourt
"Never underestimate the bandwidth of a station wagon filled with backup tapes." ("Computer Networks" by Andrew S Tannenbaum )
|
|
|
|
|
I've got code that calls this method on an open file. GetFilePath() returns the string as expected, but it sets the last error to 87 (Invalid parameter). It seems to only be happening in a release build with an open file on a CD (read-only).
Does this make sense to anyone?
J
"I am the Lorax. I speak for the trees."
|
|
|
|
|
How are you verifying this error is being set?
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
I inserted GetLastError() calls before and after the GetFilePath() call. Then I traced it.
J
"I am the Lorax. I speak for the trees."
|
|
|
|
|
Like this?
int x = GetLastError();<br />
CString str;<br />
str = file.GetFilePath();<br />
x = GetLastError();
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Yup. And I traced into the MFC code, but of course I can't add that code around the 3 or 4 API calls below CFile::GetFilePath().
J
"I am the Lorax. I speak for the trees."
|
|
|
|
|
Strange, as I see no calls to SetLastError() in filest.cpp. And for GetFilePath() to return data whilst also setting the error value is odd. Usually when a functions sets an error, no useable data is returned.
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
DavidCrow wrote:
Strange, as I see no calls to SetLastError() in filest.cpp.
Well, GetFilePath() makes several API calls. These typically return a value indicating an error has occurred and set the last error value.
DavidCrow wrote:
And for GetFilePath() to return data whilst also setting the error value is odd.
Hence my confusion.
DavidCrow wrote:
Usually when a functions sets an error, no useable data is returned.
There are no documented error conditions in CFile::GetFilePath(). According to MSDN it shouldn't even throw any exceptions, although the example wraps the call in a try/catch block.
My code throws no exception. We only found the problem because a GetLastError() call later in the process was giving the error code when the API call legitimately didn't fail.
J
"I am the Lorax. I speak for the trees."
|
|
|
|
|
Jamie Hale wrote:
...a GetLastError() call later in the process was giving the error code...
So could SetLastError() be getting called long after GetFilePath() has come and gone?
For example, I've see instances of this type of code:
MyLoggingFunction("%d\n", SomeFunction());
DWORD dw = GetLastError();
One of two things can happen here. SomeFunction() could internally call SetLastError(0) but the above call to GetLastError() could be non-zero if MyLoggingFunction() called SetLastError(). Or, SomeFunction() could call SetLastError() with a non-zero value, but by the time MyLoggingFunction() had finished, GetLastError() is 0. Make sense?
Five birds are sitting on a fence.
Three of them decide to fly off.
How many are left?
|
|
|
|
|
Makes perfect sense.  But I was tracing through the code in the debugger. The code looked like this...
DWORD dwErr = GetLastError();
CString strFilename = f.GetFilePath();
dwErr = GetLastError();
It boggles the mind. I have a feeling it could be because the filenames were originally very long, and to write them to a CD the filenames get truncated. The filesystem on the CD could be wackified somehow. But I'm grasping at straws here.
J
"I am the Lorax. I speak for the trees."
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
