|
Thanks, I found a simple solution which I posted to the previous response.
|
|
|
|
|
Hello All,
I am converting one of our legacy programs from VB to VS2012 C#.
The problem I am having is that I need to access the inlineshapes of a word document, and I keep throwing an exception: 'Object reference not set to an instance of an object'
Here is my code.
public bool LoadMonthly(ref Document oDoc, int intIndex, DataSet ds, decimal decAvail)
{
bool bStatus = constSUCCESS;
try
{
Microsoft.Office.Interop.Word.InlineShape chartShape = oDoc.InlineShapes[intIndex];
Microsoft.Office.Interop.Graph.Chart oChart;
if (chartShape.OLEFormat.ProgID == "MSGraph.Chart.8")
{
System.Windows.Forms.MessageBox.Show("yep");
}
}
}
Sorry if I missed a paren.
The Document is an active document, I have been updating the tables up until this point.
intIndex is the index for the inlineshape object
The other parameters are of no issue at this point as I cannot get past :
if (chartShape.OLEFormat.ProgID == "MSGraph.Chart.8")
{
System.Windows.Forms.MessageBox.Show("yep");
}
or any other chartShape operation (OleFormat.Edit(), etc....).
Can someone tell me what I am missing here?
This is just a code segment, so please no comments on I'm missing catch blocks or whatever.
Thanks,
jeff
modified 26-Feb-13 17:50pm.
|
|
|
|
|
Object reference not set to an instance of an object is one of the easiest errors to find.
Either chartShape, or chartShape.OLEFormat is null.
In the debugger, set a breakpoint on the if and see what's null that shouldn't be!
|
|
|
|
|
Hi,
it sounds like the "chartShape.OLEFormat.ProgID" has not been initialised in you oDoc reference.
you need to put a break point at the first line of this method, open the local window and check that the oDoc is actually has valid
index to access the "oDoc.InlineShapes[intIndex]", if it has, check that the ProgID has been set to something.
Also you may use the reference equality ".Equals()" instead of operator equality "==" for checking references.
Regards
Jegan
Think! Don't write a line of code unless you absolutely need to.
|
|
|
|
|
chartShape.OLEFormat.ProgID being null will not cause the exception/error described.
It would just cause the if condition to be false.
However, chartShape or chartShape.OLEFormat being null will cause the exception.
|
|
|
|
|
Agree!
Think! Don't write a line of code unless you absolutely need to.
|
|
|
|
|
ok, I have most of this worked out, but do have one problem.
I have a tab delimited text file that I am reading out into a datatable in the code, then pushing that to a stored proc on sql server. That part works but here is the problem.
This file has 15 columns in it. The following code is putting EACH line into the datatable 15 times.....
using (StreamReader file = new StreamReader(@"C:\ProductionLog.txt"))
{
while ((line = file.ReadLine()) != null)
{
char[] delimiters = new char[] { '\t' };
string[] rows = line.Split(delimiters, StringSplitOptions.None);
for (int i = 0; i < rows.Length; i++)
{
dt.Rows.Add(rows);
}
}
file.Close();
}
so I am getting,
BUNDLE 01/29/13 01:42 pm 7 5" 7' 63 5 84 1 6 17.31 31.155 16 0 0
BUNDLE 01/29/13 01:42 pm 7 5" 7' 63 5 84 1 6 17.31 31.155 16 0 0
BUNDLE 01/29/13 01:42 pm 7 5" 7' 63 5 84 1 6 17.31 31.155 16 0 0
15 times( it will do line 2 after it does the 15 and does it 15 times as well), instead of
BUNDLE 01/29/13 01:42 pm 7 5" 7' 63 5 84 1 6 17.31 31.155 16 0 0
BUNDLE 01/29/13 01:43 pm 7 5" 7' 64 5 84 1 6 16.96 54.262 9 1 2
BUNDLE 01/29/13 01:44 pm 7 5" 7' 65 5 84 1 6 17.56 33.712 15 4 0
and so on.
Can somebody tell me how much of a dumn** I am being and how to fix this?
Treat stressful situations like a dog, if you can't eat it, play with it or screw it, then just piss on it and walk away.
Be careful which toes you step on today, they might be connected to the foot that kicks your butt tomorrow.
|
|
|
|
|
Don't you just want:
dt.Rows.Add(rows);
|
|
|
|
|
|
I've implemented owner drawing when adding items to a listbox. I won't waste time going into it but where I have hit a problem is with colours. Our application will read a column containing an ARGB value for a colour. This value is put into the Color.FromArgb method which returns a Color object which is then applied to the listbox value. If I use exclusively named colours like Color.Red, Color.LimeGreen that sort of thing the listbox is drawn 100% fine. But if the ARGB value isn't a named colour it fails to render anything. It effectively leaves me with white text on a white background.
Has anyone used other than named colours when painting listbox items using OwnerDrawVariable?
As I say, it works perfectly for named colours but the moment I use an ARGB value which isn't a named colour it doesn't actually do anything.
There is a method in the graphics object called GetNearestColor. I tried pumping my ARGB value into it but the Color object it emits is exactly the same as what I sent it. In other words, it doesn't convert a colour that's approximately "slightly like fuschia" for example into Fuschia which is what GetNearestColor is supposed to do. The colour that's in the database is selected by users with the colour picker dialog and they can select any colour or pick one of their own.
Curiously, the same ARGB value works perfectly in a Treeview control.
Any ideas?
"I do not have to forgive my enemies, I have had them all shot." — Ramón Maria Narváez (1800-68).
"I don't need to shoot my enemies, I don't have any." - Me (2012).
|
|
|
|
|
I don't think you'll get an answer to this question unless you reveal the code employed to draw an item and example ARGB values that fail.
PHS241 wrote: This value is put into the Color.FromArgb method which returns a Color object
which is then applied to the listbox value.
That is just too vague.
Alan.
|
|
|
|
|
Well, like Alan said, without seeing your owner-drawing code and an example of a value that fails, the best anyone call tell you is "you screwed up your rendering code".
|
|
|
|
|
Guys,
I found the answer which I'll share. As I said, the treeview displayed the node in the right text colour and background colour. The same ARGB value applied to owner drawing in the listbox did not. The problem was the alpha component. The treeview seems to be more forgiving and accepts alpha values of 0 and 255 as one and the same. The listbox renders alpha values of 0 as fully transparent and 255 as fully opaque which is perhaps the correct result. For a listbox then, I need to force the alpha value to 255. Here is a sample code snippet:
const int anyArgbValueHere = 16744703;
Color argb = Color.FromArgb(anyArgbValueHere);
Color correctedArgb = Color.FromArgb(255, argb.R, argb.G, argb.B); // Same colour but with alpha forced.
When I paint the listbox it now works fine. Obviously, it would be better to have a method that does the conversion as you'd need to handle cases where the colour's IsEmpty property is true.
So, alpha was the problem and not a fault with my owner drawing.
"I do not have to forgive my enemies, I have had them all shot." — Ramón Maria Narváez (1800-68).
"I don't need to shoot my enemies, I don't have any." - Me (2012).
|
|
|
|
|
I would have assumed your drawing code would have handled this situation.
|
|
|
|
|
You mean something like:
using System.Hindsight.Wonderful.Thing
"I do not have to forgive my enemies, I have had them all shot." — Ramón Maria Narváez (1800-68).
"I don't need to shoot my enemies, I don't have any." - Me (2012).
|
|
|
|
|
probably something really dumb but I can not multiple floats and come up with anything but a whole number.
for example
float x = 200031010f;
float y = .86f;
float z = x * y;
I would expect z to be 1722668.6 but it is 1722668
Convert.ToSingle also truncates it to the whole number when converting a double.
what good is a float if multiple just gives whole numbers?
|
|
|
|
|
The float data-type[^] has a maximum precision of 7 digits. The result of your calculation requires 10 digits, and therefore cannot be stored accurately in a float.
I'm assuming you have a typo in your question. The actual result should be 172026668.6; the truncated result in a float is 172026700.
You should use either the double data-type[^], which has a precision of 15-16 digits, or the decimal data-type[^] which has more precision but a smaller range.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
You are losing precision as the float type is not big enough for these numbers. Change to double (which you should always use) and it works.
Use the best guess
|
|
|
|
|
durn. I am converting some code in vb6 that passes a single value in a string used in password calculations. I can't use double because the message is for 4 bytes. I need to figure out how to get c# to calculate the same numbers in the same byte format.
in vb6 20031010 * .86 returns
1.722667E+07
1,722,668 is not a very large number and if you can't have more than 7 significant digits it kind of defeats the purpose of having a floating point number is the first place. microsoft says a float has a range of
-3.4 × 10^38 to +3.4 × 10^38
|
|
|
|
|
notahack wrote: microsoft says a float has a range of -3.4 × 10^38 to +3.4 × 10^38
Microsoft also says that float has a precision of seven digits.
Remember that a floating-point number can only approximate a decimal number, and that the precision of a floating-point number determines how accurately that number approximates a decimal number. By default, a Single value contains only 7 decimal digits of precision, although a maximum of 9 digits is maintained internally. The precision of a floating-point number has several consequences:
- Two floating-point numbers that appear equal for a particular precision might not compare equal because their least significant digits are different.
- A mathematical or comparison operation that uses a floating-point number might not yield the same result if a decimal number is used because the floating-point number might not exactly approximate the decimal number.
- A value might not roundtrip if a floating-point number is involved. A value is said to roundtrip if an operation converts an original floating-point number to another form, an inverse operation transforms the converted form back to a floating-point number, and the final floating-point number is equal to the original floating-point number. The roundtrip might fail because one or more least significant digits are lost or changed in a conversion.
notahack wrote: in vb6 20031010 * .86 returns 1.722667E+07
And in C#, 20031010f * .86f returns 1.722667E+07. What's the problem? 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
the problem is it does not return 1.722667E+07, it returns 1722668.0
I must be special.
|
|
|
|
|
I've just tried this in .NET 4.0 and 3.5, and the result is the same in both:
float x = 20031010f;
float y = .86f;
float z = x * y;
Console.WriteLine(z);
Console.WriteLine("{0:F}", z);
Output:
1.722667E+07
17226670.00
If your code is returning 1722668.0 then you're doing something wrong; that's off by a factor of 10.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
you are correct and my results are even more evil 17226668.0
I don't doubt I am doing something wrong but really the code is exactly as you demonstrated, simple simple but frustrating.
|
|
|
|
|
Try this:
float z = 20031010f * .86f;
Debug.WriteLine( z.ToString("G") );
The two values ARE equal internally. What you see on screen is just the differnt ways the two environments chose to represent the STRING version of those numbers.
|
|
|
|
|
Yes, but a type like float cannot represent all of the numbers in that range since there are an infinite number of them!
How it works is there are a finite number of bits (32 in this case) to store a floating point value, split into 3 seections. The first bit is the sign bit. The next 8 bits are the exponent value and the remaining 23 bits are the fraction value. This gives you a sum total of 7 digits of numeric representation.
What does that mean? Well, if you want to represent a very large number, the format sacrifices accuracy by rounding off the least significant digits of the fraction value and increasing the value of the exponent to scale the fractional part of the number to the appropriate range.
decimal 10 = 0000001 * 10 ^ 1 (10 ^ 1) = 10
^ ^
| |
fraction exponent
decimal 1234567 = 12D687 * 10 ^ 0 (10 ^ 0) = 1
1234567 can be represented by 21 bits: 1 0010 1101 0110 1000 0111
so it fits inside the 23 bits available for the fraction part.
decimal 12345678 = ??????
Hmmmm... This requires 24 bits to represent: 1011 1100 0110 0001 0100 1110
This won't fit inside the 23 bit fraction part!
What to do, what to do, .... ??
The answer to this little problem is simple. Sacrifice a little precision and use scientific notation! Divide the number by 10 (remember what the exponent is raising) and round it off! This gives us 1234567.8 = 1234568.0. Now, we've got a 7 digit number that fits inside 23 bits. But there's that pesky division we did. Since we divided by 10, we have to raise the value of the exponent to compensate: 10 ^ 1. Now our number looks like this: 1234568.0 * 10 ^ 1, or 1.234568 * 10 ^ 7.
That's the quick'n'grossly simplified version of what's going on. For more read this[^]
modified 26-Feb-13 15:17pm.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
)