|
Try using the Value property of the cell instead of the Text property of the column. Maybe not the best answer, but it produces the behaviour I think you're after.
Like so...
private void Form1_Load(object sender, EventArgs e)
{
DataGridViewLinkColumn col = new DataGridViewLinkColumn();
dataGridView1.Columns.Add(col);
for (int i = 0; i < 4; i++)
{
DataGridViewRow dr = new DataGridViewRow();
dataGridView1.Rows.Add(dr);
}
for (int i = 0; i < 4; i++)
dataGridView1.Rows[i].Cells[0].Value = "view";
}
private void dataGridView1_CellClick(object sender, DataGridViewCellEventArgs e)
{
dataGridView1.Rows[e.RowIndex].Cells[e.ColumnIndex].Value = "hide";
}
|
|
|
|
|
Hi ,
I have a problem with print in crystal report using VS2003.
[CODE]
CrystalRpt rptdoc = new CrystalRpt();
System.Drawing.Printing.PrintDocument printDocument = new System.Drawing.Printing.PrintDocument);
rptdoc.PrintOptions.PrinterName = printDocument.PrinterSettings.PrinterName;
rptdoc.PrintToPrinter(1, true, 0, 0);
[/CODE]
CrystalRpt is the crystalreport that I use.
when user clicks cancel in the print dialogbox that appears, it throws the error.
Please find the stack trace below:
************** Exception Text **************
CrystalDecisions.CrystalReports.Engine.InternalException: Error in File C:\DOCUME~1\RAKESH~1.RED\LOCALS~1\Temp\temp_d047ddc7-9297-4a24-a03f-11f21917120a.rpt:
Request cancelled by the user.
at .I(String , EngineExceptionErrorID )
at .D(Int16 , Int32 )
at .C(Int16 )
at CrystalDecisions.CrystalReports.Engine.FormatEngine.PrintToPrinter(Int32 nCopies, Boolean collated, Int32 startPageN, Int32 endPageN)
at CrystalDecisions.CrystalReports.Engine.ReportDocument.PrintToPrinter(Int32 nCopies, Boolean collated, Int32 startPageN, Int32 endPageN)
at SampleCrystal.Form1.btnPrint_Click(Object sender, EventArgs e)
at System.Windows.Forms.Control.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnClick(EventArgs e)
at System.Windows.Forms.Button.OnMouseUp(MouseEventArgs mevent)
at System.Windows.Forms.Control.WmMouseUp(Message& m, MouseButtons button, Int32 clicks)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.ButtonBase.WndProc(Message& m)
at System.Windows.Forms.Button.WndProc(Message& m)
at System.Windows.Forms.ControlNativeWindow.OnMessage(Message& m)
at System.Windows.Forms.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr
********************************************************************************
**********
When I implement the same code using VS2008, i dont get the error.I found it specific in VS2003.
Thanks in advance.
Rakesh Reddy
|
|
|
|
|
Most people use 96 DPI, but occasionally people set this to 120 DPI (or even higher), especially with high resolution monitors that display at greater than 100 DPI. This number is easy to get under Win32 ("LogPixels") and I've done it for years. But I'm relatively new to .NET and haven't been able to find out what .NET API delivers this number. This is such an important parameter that there must be a simple API to get it under .NET. Does anyone know what it is? This is especially important from Vista onward which doesn't believe in physical pixels, but merely device independent units.
Matthew MacDonald's Pro WPF in C# 2008, chapter 1, has a good discussion of device independent DPI scaling but nowhere does he say how to obtain this crucial number. I need the number because I have to scale the numbers that come back from the monitor enumeration, which specifies, x,y, height, and width, to fill the screen with a bitmap. All these numbers have to be scaled back by a factor 96/x, where x is the DPI Scaling number.
If worse comes to worse, I'll use Interop services to get the number, but I cringe every time I do that, thinking that I've just missed something in .NET.
Addendum: I can also get this number from the Registry: [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontDPI]"LogPixels" but that's even more of a hack than Interop Services. The cleanest way would be through a .NET API.
modified on Monday, July 20, 2009 12:36 PM
|
|
|
|
|
Graphics g = this.CreateGraphics();
MessageBox.Show(g.DpiX.ToString() + Environment.NewLine + g.DpiY.ToString());
g.Dispose();
g = null;
this is a Form in the above snippet
|
|
|
|
|
Ah, I should have mentioned that this is a WPF application, not a Forms application. Last time I posted a question in the WPF forum I was castigated for posting a general .NET question in the wrong forum, when I thought it was a WPF question. Damned if you do and damned if you don't.
There are classes in WPF that return properties, DpiX and DpiY, such as BitmapImage, but those are the DPI x and y of particular bitmaps. I tried with a JPEG image I had lying around and it returned 300, which was a property of the bitmap, not the DPI Scaling number that the user has set up for his entire system.
I looked around and couldn't find a WPF equivalent to the CreateGraphics() call that your example gives.
Well, I guess I'll post my question on the WPF forum.
|
|
|
|
|
Hi,
I fail to see why
Bitmap bitmap=new Bitmap(100, 100);
Graphics gBM=Graphics.FromImage(bitmap);
Console.WriteLine("DpiX="+gBM.DpiX);
gBM.Dispose();
wouldn't work in a WPF app?
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get.
Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
|
|
|
|
|
Luc Pattyn wrote: I fail to see why...wouldn't work in a WPF app?
I believe it would if I was allowing my WPF application to interact with Windows Forms, but so far I've managed to "remain pure" and avoid all contamination with that superceded paradigm. I hope I'm not giving offense by characterizing Windows Forms that way. But it does seem clumsy and ad hoc compared to the regularity of WPF. The problem with WPF is that there are gaps in it: it was "rushed into print" before achieving functional closure. This is why I've had to resort to Interop facilities so much in my application. Hopefully .NET 4.0 will fill in the holes.
|
|
|
|
|
fjparisIII wrote: The problem with WPF is that there are gaps in it; ... before achieving functional closure
Have you read some of the "why WPF sucks today" messages that appear all over the Lounge? They made me postpone my first WPF encounter for a few years, since that is the time it normally takes Microsoft to get something from an available product or technology to a usable product or technology.
From what I've read, the problems are:
- there are more holes than there is cheese;
- half of it does not work;
- Visual Studio 2008/2010 crashes on all but the smallest WPF apps;
- Expression Blend crashes too.
So, yes I like the theoretical concepts of WPF, and I await better times.
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get.
Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
|
|
|
|
|
Luc Pattyn wrote: Have you read some of the "why WPF sucks today"
Until I'm blue in the face. Most of these people seem to be whiners that want to be hand-held through projects and are afraid of doing a little digging.
But I've got 80,000 lines of pure WPF code (and a smattering of Interop contamination) in my applications and my beta testers (advanced and professional photographers) love it. (I'm looking for active beta testers, BTW.)
The biggest problem I've had is working around puzzling limitations like why is the BackgroundWorker class an [STMThread] and not an [STAThread]. It prevents BitmapEncoder.Save() from executing without causing an arithmetic overflow exception, probably because the class instance can't be initialized under MTA. Inquiries to Microsoft land on deaf ears, but a lot of people have complained, so they know about this.
I finally had to resort to writing my own StaBackgroundWorker class that does the same thing as BackgroundWorker except it runs STA rather than MTA. If you're not willing to go the extra mile once in a while, then state of the art technlogies are probably not for you, or your company.
And Expression Blend is for sissies.
|
|
|
|
|
Very interesting. So there is hope.
Would you consider writing an article? Seems you could tilt the balance a bit on WPF...
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get.
Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
|
|
|
|
|
Luc Pattyn wrote: Would you consider writing an article? Seems you could tilt the balance a bit on WPF...
I'm not sure. An article on what? I know, something on WPF, but in spite of what I've done the last 4 months, I'm far from a WPF expert. Just a coding (and, admittedly, a documentation) maniac. I constantly live out of books, MSDN, and Google searches, and am hardly authoritative.
|
|
|
|
|
IMHO an article that explains a real-life WPF application would be worthwhile; it doesn't have to be very technical, however telling about the components used, shedding some light on how they were used, what some of the problems and solutions were, etc. would encourage people to try and use WPF themselves. Of course there are some articles already, but yours seems a bigger, more realistic application, and it not being very high-tech may be a plus.
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get.
Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
|
|
|
|
|
Maybe something when I'm out from under this current project. There are some interesting solutions I have in this application, like the way I save hundreds of configuration parameters in an XML file in the Users folder and totally avoid touching the Registry.
This application is based on an MFC CPropertySheet/CPropertyPage application that had about 10 tabs on it. I gave it away free to advanced and professional photographers all over the world. My current beta testers are largely taken from the owners of the original. Its reincarnation has much more professional polish and has about 70 different pages, which of course can't be arranged in a tabbed dialog. Instead its "menu" is a hierarchically organized tree control in a panel on the left with the pages displayed in a panel on the right.
modified on Monday, July 20, 2009 8:45 PM
|
|
|
|
|
yep. The Graphics class has a DpiX and DpiY property (I have never seen them different). You can get a Graphics object from a Control, or from an Image or Bitmap (they default to a screen-compatible Graphics). It would become tricky if and when you have several monitors with different properties...
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get.
Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
|
|
|
|
|
As I mentioned, I have a WPF application so can't (or don't want to) use the proposed solution with the Graphics class. I want my WPF application to remain "pure", not mixing Forms stuff in it. On the other hand, I already have gobs of Interop stuff in it, so it isn't "pure" anyhow. For example, I use Interop stuff to enumerate all of the attached monitors so I can get their x,y,width,height properties in pixels. That's exactly my problem. I can only use those numbers as Win32 presents to me if the system DPI is set to 96. If set to 120 (for example) I have to scale them with a factor 96/120.
Luc Pattyn wrote: It would become tricky if and when you have several monitors with different properties...
I do have to render photographic bitmaps on different monitors each of which probably do have different resolutions. But I think the DPI Scaling number applies to the operating system as a whole. The Control Panel does not distinguish between monitors. So I don't think anything "tricky" will be involved, and I already support multiple monitor systems with radically different screen resolutions with no problem.
In any case, I think this is a WPF question, not a .NET question in general, so I've posed the question on the WPF forum.
|
|
|
|
|
fjparisIII wrote: But I think the DPI Scaling number applies to the operating system as a whole
AFAIK that is completely wrong. Yes the Vista control panel has separated the DPI stuff from the Display Settings stuff, however I am convinced under the hood the DPI setting is just one of the Display Settings, and exists separately for each display.
fjparisIII wrote: I've posed the question on the WPF forum
I don't read the WPF forum, however I'm interested in this specific item. So I wouldn't mind if you were to signal a solution here as well (if and when you get one that is).
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get.
Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
|
|
|
|
|
Luc Pattyn wrote: I am convinced under the hood the DPI setting is just one of the Display Settings, and exists separately for each display.
I would be delighted to see some actual proof of this. All I can tell you is that my application is working perfectly fine with widely varying resolutions from multiple monitors attached to the system.
Luc Pattyn wrote: I wouldn't mind if you were to signal a solution here as well (if and when you get one that is).
If I get a solution, I'll cross-post it here. I wouldn't be surprised if I have to resort to the Registry hack. That would be very easy to implement, however, much easier than hassling with mixing Windows Forms with my WPF app, but of course vulnerable to the exigencies of humans screwing up the Registry.
|
|
|
|
|
fjparisIII wrote: I would be delighted to see some actual proof of this
AFAIK WinXP lets you choose color depth and DPI resolution for each monitor individually (under Display Settings/Settings/Advanced).
I will investigate when I can, unfortunately I don't have a spare monitor available right now. It may take a couple of weeks.
This[^] seems to suggest Vista is a (temporary?) step back in this respect.
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get.
Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
|
|
|
|
|
To tell you the truth, I'd be surprised if this gets "fixed" for Windows 7 and am shocked to hear that it was in XP. I think the wave of the future is to have higher density monitors and most "balanced" systems won't mix 96 DPI monitors with 144 DPI monitors. That said, I haven't yet seen stand-alone monitors much above 100 DPI. But I don't see how you can hold the technology back. Who wouldn't like 3840x2400 24" monitors running at 192 DPI? You could stick your nose in images and see further details. Photographers would fall over themselves for such a monitor.
|
|
|
|
|
I own a 17" laptop with 1900*1200 or so pixels, so that is really 144 dpi and I am sure I've set it at that with the Display Settings (I even created a little app to temporarily switch back to a lower resolution in order to have an easier read on some web sites, that was before there was FireFox with its zoom facilities). That laptop always has been running XP.
And I am almost sure I did connect an old external LCD monitor to it, the only one I have is a 16" with 1280*1024 pixels, which would be close to 96 dpi; I can't imagine having compromised anywhere, so that's what makes me say XP can handle the combination. I don't have the monitor around right now, when I have it back, I will try and make sure.
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get.
Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
|
|
|
|
|
Hi,
there is a way to get a display's DPI value through WMI, it is the "LogPixel" field you would need from the Win32_DisplayConfiguration class, so it gets stored for each display individually.
BTW: this retrieval is both Forms and WPF agnostic and does not need P/Inwoke or any Win32 API. However there is one drawback: the first WMI query does tend to take up to one second to execute.
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get.
Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
|
|
|
|
|
I got the answer from the WPF forum, where I cross-posted. Here is the code, and it is indeed WPF-specific as I knew it would have to be after getting a suggestion from a Windows Forms programmer on this forum. It is actually much more elegant than the Forms suggestion, one more indication of the superiority of WPF over Windows Forms. It is device-specific! So if Microsoft ever does get around to supporting individual DPI Scalings per monitor, this code will work without change.
Consider the following code snippet:
_left = Monitor.Rect.left;
_top = Monitor.Rect.top;
_width = Monitor.Width;
_height = Monitor.Height;
Matrix m = PresentationSource.FromVisual(this).CompositionTarget.TransformToDevice;
double dpiX = m.M11;
double dpiY = m.M22;
_left /= dpiX;
_top /= dpiY;
_width /= dpiX;
_height /= dpiY;
The original values of _left, _top, _width and _height are the direct result of the monitor properties of the monitor the code is going to display images on. dpiX and dpiY are then the DPI scaling factors of the X and Y directions of that monitor. for 96 DPI (the standard) the values are 1.0. For 120 DPI, the values are 1.25. So I just scale the four monitor dimensions and Voila! Absolute perfection for this particular monitor.
End of story.
|
|
|
|
|
At the MSDN forum a MVP posted a sample explaining HandleRef:
MyObject myObject = new MyObject();
IntPtr handle = myObject.GetHandle();
NativeMethods.SomeNativeFunction(handle);
I don't understand how the value of handle can become invalid, handle is of type IntPtr which is a value type living on the stack until the method where handle is defined returns.
|
|
|
|
|
stax76 wrote: handle is of type IntPtr which is a value type living on the stack
It's a pointer, meaning that it "points" to something else (usually a reference type). It could be pointing to a form, and that form may already have been disposed whilst the pointer is still there.
ForumSig
|
|
|
|
|
I think I get it now but still I think for the rare cases where something actually could get GC'ed it's much easier to keep a reference in order to prevent it to be collected by the GC instead of creating all this pointless HandleRef instances that will never be really needed. Some result but shorter code. For a library where it's not clear how the code will be used maybe it's more important.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Badger | [badger,badger,badger,badger...]](https://www.codeproject.com/script/Forums/Images/badger.gif)
