|
Hi.
I have created a dll from C code using MinGW. I try using it in my C# code, the code compiles, but the executable always hangs. If I use the dll in plain C code, the executable runs fine. I've gone through several tutorials and the dll always hangs if I try to run my compiled C# code. For reference, the last tutorial I attempted was this one.
What am I doing wrong? How can I access a dll, compiled with gcc under MinGW, in my C# code?
|
|
|
|
|
dfn wrote: What am I doing wrong?
Hard to say if you don't post your C# calling code.
|
|
|
|
|
Hi,
How can I get, the screen resolution of user by coding.
|
|
|
|
|
Screen.PrimaryScreen
It may be Screens.PrimaryScreen.
Christian Graus - Microsoft MVP - C++
"also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
|
|
|
|
|
Thanks for your quick reply,
I don't understand your answer. I want to write a code to get computer's monitor's screen resolution.For example 1024x768 pixel. When, I changed the resolution from windows's normal options, I want to see it by clicking one button for example.
|
|
|
|
|
http://msdn2.microsoft.com/en-us/library/system.windows.forms.screen.primaryscreen(VS.71).aspx[^]
Like I said, Screen.PrimaryScreen gets you access to properties of the main screen on the PC
Christian Graus - Microsoft MVP - C++
"also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
|
|
|
|
|
Oh, screen dimensions are available through the Screen class, as in
Screen.PrimaryScreen.Bounds
Luc Pattyn [Forum Guidelines] [My Articles]
this months tips:
- use PRE tags to preserve formatting when showing multi-line code snippets
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
I understood,
Thanks so much for your interest,
|
|
|
|
|
Hi,
The Graphics class has DpiX and DpiY properties, so you could capture them in an OnPaint
method.
Also the Graphics that gets created from a neutral image seems to take the current
screen's resolution, so you can do:
Bitmap bitmap=new Bitmap(100, 100);
Graphics gBM=Graphics.FromImage(bitmap);
Console.WriteLine("DpiX="+gBM.DpiX);
gBM.Dispose();
Remarks:
- on XP that setting is hidden somewhere in the Display Properties window
- by default a monitor seems to be set at 96 dpi, which does not necessaraly reflect
the real hardware's characteristics
- when you calculate it yourself, you typically get a higher number (say 120 to 148).
- if you change the Display Properties settings, you will get a bigger desktop, with
everything a lot smaller...
- I have never seen a situation where DpiX!=DpiY (which matches the fact that you can
only set one resolution, good for square pixels only)
Luc Pattyn [Forum Guidelines] [My Articles]
this months tips:
- use PRE tags to preserve formatting when showing multi-line code snippets
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
|
I'm attempting to create an application that can call .BAT files to handle tasks.
The BATCH file runs fine EXCEPT for the XCOPY call. Everyting works from a CMD window. Would .NET not allow an XCOPY execution?
Here's the code that creates the process and the calling code:
public string runProcess(string sCommand, string sArgs, bool bRedirectStandardOutput, bool bUseShellExecute)<br />
{<br />
Process seiProcess = new Process();<br />
seiProcess.StartInfo.FileName = sCommand;<br />
seiProcess.StartInfo.Arguments = sArgs;<br />
seiProcess.StartInfo.RedirectStandardOutput = bRedirectStandardOutput;<br />
seiProcess.StartInfo.UseShellExecute = bUseShellExecute; <br />
bool bStart = seiProcess.Start();<br />
<br />
if (bRedirectStandardOutput)<br />
{<br />
seiProcess.OutputDataReceived += new DataReceivedEventHandler(SortOutputHandler);<br />
seiProcess.BeginOutputReadLine();<br />
}<br />
<br />
seiProcess.WaitForExit();<br />
seiProcess.Close();<br />
return processOutput;<br />
}<br />
<br />
String r = util.runProcess(@"..\copysomething.bat", @"G d:\dvd", true, false);<br />
The batch file that is executed by the .NET app:
<br />
@ECHO OFF<br />
echo STARTING AT<br />
TIME /T<br />
xcopy %1:\* %2<br />
The above BATCH file will display the time correctly, so I know it's getting called!
Thanks in advance,
C
|
|
|
|
|
No, there's nothing in the .NET Framework that would stop XCOPY from running. Everything LOOKS fine. The problem is that the method you're using to copy the files isn't very robust and lacks any error reporting.
Can I ask why you're even bothing with XCOPY when there are native classes/methods in the .NET Framework System.Io namespace that will do the copy, and provide you with far better error reporting?
|
|
|
|
|
The structure to this process is an artifact of the solution. We need "scriptability" to allow customers to customize the actions.
What I don't understand is that the script tests fine:
D:\docs\Visual Studio 2005\Projects\RoboStation\bin>dcs-anydvd-copy.bat G d:\Temp theFolder
STARTING AT
12:53 PM
AnyDVD Window Handle: 0x0002014E
One on: 1
G:\* d:\Temp\theFolder /S /I <--proof that the parameters are working
G:\JACKET_P\J00___5L.MP2
G:\JACKET_P\J00___5M.MP2
G:\JACKET_P\J00___5S.MP2
G:\VIDEO_TS\VIDEO_TS.BUP
G:\VIDEO_TS\VIDEO_TS.IFO
G:\VIDEO_TS\VIDEO_TS.VOB
G:\VIDEO_TS\VTS_01_0.BUP
G:\VIDEO_TS\VTS_01_0.IFO
G:\VIDEO_TS\VTS_01_0.VOB...................
I know the script is called properly in terms of passing the parameters. I wonder if XCOPY needs additional enviromental settings like "Working Directory".
I will test that hypothesis.
|
|
|
|
|
ckelker wrote: I wonder if XCOPY needs additional enviromental settings like "Working Directory".
Nope, it doesn't. The only thing it needs is folly qualified paths to the source and destination.
The problem is the output redirect. XCOPY doesn't like having it's output redirected. Turn it off and it works fine.
|
|
|
|
|
You are correct! Can you recommend a resource that would have little nuggets of information like 'XCOPY doesn't like redirect output' for DOS commands to be used in this scripts?
CK
|
|
|
|
|
The only resource for stuff like that is trial-and-error.
|
|
|
|
|
Hi.
So far my app runs great. Apart from some slow performance, but that's not too important.
using System.Drawing I'm making use of a Panel control and drawing using .CreateGraphics()
What I'd like to know is, is there any way of getting a System.Graphics object for an Image or a Bitmap, so that I can draw to the bitmap in memory (using FillRectangle, etc.) and then dump the Bitmap onto the Panel control when the paint event comes a-knocking?
Basically, what's the equivalent of Control.CreateGraphics() for a Bitmap?
Cheers,
Ninja
Ninja (the Nerd)
Confused? You will be...
|
|
|
|
|
Ninja-the-Nerd wrote: drawing using .CreateGraphics()
Never do this. Open your app. Open Calculator. Drag calculator over your app. See how your painting all disappears ? That's because you used CreateGraphics. Handle the paint event of your control instead.
Ninja-the-Nerd wrote: What I'd like to know is, is there any way of getting a System.Graphics object for an Image or a Bitmap,
Graphics.FromImage
Ninja-the-Nerd wrote: when the paint event comes a-knocking?
You call CreateGraphics in a paint event ? Why ?
Christian Graus - Microsoft MVP - C++
"also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
|
|
|
|
|
"You call CreateGraphics in a paint event ? Why ?"
I don't. I assure you, even 3 years of VB.NET didn't make me THAT bad. What the app does is create an instance of a class which contains a whole lot of drawing code and pass it a reference to the control it draws to.
Then it adds its own handlers for the Resize & Paint events of the control, and updates the Graphics object accordingly.
The paint event calls the drawDisplay() event, which uses the Graphics object to draw (fill) rectangles and text to the control.
The resize event is the only thing that ever calls CreateGraphics().
What I want to do is to be able to store a copy of the Image last drawn, and only necessitate that the image be redrawn when the display is scrolled. Otherwise, the paint event will simply draw the last image drawn.
I did have a Image lastImage for this, but using displayPanel.DrawToBitmap doubled my draw time and would only draw the control as a background colour.
"Graphics.FromImage"
So if I set my Graphics object like this I'll be able to use DrawString & FillRectangle to draw directly to the Bitmap in memory, then draw said Bitmap to the control using e.Graphics.DrawImage() ?
*realises how badly explained it was first time*
Ninja (the Nerd)
Confused? You will be...
|
|
|
|
|
Ninja-the-Nerd wrote: So if I set my Graphics object like this I'll be able to use DrawString & FillRectangle to draw directly to the Bitmap in memory, then draw said Bitmap to the control using e.Graphics.DrawImage() ?
Correct.
Christian Graus - Microsoft MVP - C++
"also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )
|
|
|
|
|
Excellent. Just starting to wrestle with the limits of Image and Bitmap being different, and wondering why new Bitmap(1, 1) can be assigned to an Image. Either way, a couple of method changes ought to have the app working great. And now, I can get on with reality (or, pseudo-reality at least).
Thanks for your help.
Ninja (the Nerd)
Confused? You will be...
|
|
|
|
|
Hi,
FYI: if you want to paint to the screen, do it in the Paint handler, without CreateGraphics,
as Christian said.
if you want to paint into a Bitmap, use Graphics.FromImage() and don't
forget to dispose of the Graphics as soon as you're done painting in it.
Luc Pattyn [Forum Guidelines] [My Articles]
this months tips:
- use PRE tags to preserve formatting when showing multi-line code snippets
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
What's the hurry with disposing it? I'd rather keep it and use it later (memory is no object, I have something like 500MB spare on my target machine). OK, if Graphics leaks then it'll become a problem, the app will be running for 2-2.5 hours, but CreateGraphics is only called upon creation, and resizing, which will typically be done once.
Ninja (the Nerd)
Confused? You will be...
|
|
|
|
|
Ninja-the-Nerd wrote: What's the hurry with disposing it? I'd rather keep it and use it later
There is no point in keeping the Graphics, it is only valid for the one Bitmap from which
it got created; if you get another Bitmap, same or diferent size, you would need another
Graphics object. And Graphics objects are expensive, they take lots of memory and occupy
some system resources that may be expensive, meaning your system may slow down significantly
or hang completely when they run low.
so by definition "once you are done painting in it" as I put it, you
should dispose of it; later on, you can save the image to disk, or paint it to the
screen, or whatever, but for these operations the Graphics you've got from FromImage
is no longer useful.
Luc Pattyn [Forum Guidelines] [My Articles]
this months tips:
- use PRE tags to preserve formatting when showing multi-line code snippets
- before you ask a question here, search CodeProject, then Google
|
|
|
|
|
Hmm. Well, being a noob with GDI (or anything more complicated than FillRectangle)...I really shouldn't argue a point, but...
If I keep it;
I get to use it during the search method which scans a text source for a result and then draws a message to the screen.
I get to update the image at will, without needing to re-get the Graphics object.
I mean, it's based on the same Image which is updated on the resize event, but the Graphics object is recreated just after that for the new Image.
Like I said, I have typically, 1GB of RAM spare on my dev machine and almost 600MB, I think, on the target machine. A few Graphics objects won't kill the system. OK, if the core part of Windows runs out of memory then, oops, but I haven't hit that eventuality yet.
As for slowing down, my dev machine, 2.6GHz Core2Duo Intel with a Radeon 2600 Pro, draws a typical screen (measured inaccurately using Environment.TickCount) in 31 or 46 "Ticks". Slow code, eh.
My 2GHz AMD Athlon which is about 4 years old, has DDR and not DDR2 RAM, and a Radeon 9200 using AGP and not PCI-E...can draw exactly the same screen completing in either 0 or 15 "ticks".
  Pretty new system, compared with 4 year old technology that sits in a cold room for weeks at a time. The only thing I can think of is the old machine has very little more than XP, .NET 2, and DirectX. The new machine has a fair bit more on it but not enough for a 3x slowdown.
Ninja (the Nerd)
Confused? You will be...
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
