|
BillWoodruff wrote: I assume you altered some attribute, some value, some setting, in the instance
of the DevX Control on a Form ... yes ?
Yes, I simply alter a value in the Property Editor while using the Forms Designer.
BillWoodruff wrote: The other question is about to what extent this problem is reliably
reproducible: can you say, for a fact, that if you alter property 'x' of the
DevX control, build the app, run it, then quit the app, that this will fail
after exactly #n times.
It will fail the first time I attempt to run the application after I make a change to a property of the DevExpress control. It does the same thing for EVERY DevExpress control. It also does the same for a custom control which I acquired here on CP. One modification to the control in the designer and it flips out. :P
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
Hi Matt, In this case I would definitely report an issue to DevX, and check on their forums to see if anyone else is experiencing this, or if there's any fix. While I have not used DevX controls myself, they do have a great reputation for support, and quality, imho.
One final question: when you first used the DevX free controls, did they require conversion by VS 2010 to be compatible with whatever FrameWork version you are compiling against. If so, did you look at the conversion error report, if there was one: might be a clue there ?
best, Bill
"In the River of Delights, Panic has not failed me." Jorge Luis Borges
|
|
|
|
|
Thanks, Bill. No, they did not require conversion by VS.
But I have also encountered this issue with any other custom control. One which I found here on CP. And if I create my own custom controls I experience the same issue. Should I still contact their support?
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
Matt U. wrote: But I have also encountered this issue with any other custom control. One which I found here on CP. And if I create my own custom controls I experience the same issue. Should I still contact their support?
Wow, well ... if you have this problem with any custom control, then, okay, it's certainly not just a DevX problem.
I'm baffled ! By the way, which version of VS 2010 are you using ?
best, Bill
"In the River of Delights, Panic has not failed me." Jorge Luis Borges
|
|
|
|
|
I am running VS 2010 Ultimate.
I have the same copy installed at home. I have also encountered the issue on my home computer. Same version of VS. The only difference is the fact that my home computer is 32-bit and this work computer is 64-bit, both Windows 7 Professional.
djj55: Nice but may have a permission problem
Pete O'Hanlon: He has my permission to run it.
|
|
|
|
|
Hello,
I have an input parameter which is defined as a bigint in SQLserver. I am using the Convert.ToInt64, to cast this variable before sending over to database. I am receiving this error - any thoughts to convert to another data type in C#? Long is not listed as an option.
C
Arithmetic overflow error converting expression to data type int. do nothing
|
|
|
|
|
long and System.Int64 are essentially the same and should work with BigInt. Posting your code might help us identify your issue.
Alternatively, you can try using SqlInt64[^]
|
|
|
|
|
SqlParameter enteredBy = new SqlParameter("@enteredBy", SqlDbType.BigInt);
enteredBy.Direction = ParameterDirection.Input;
enteredBy.Value = Convert.ToInt64(Session["CMSID"]);
sqlcommStoredproc.Parameters.Add(enteredBy);
|
|
|
|
|
Are you sure session["CMSID"] is a 64 bit int? People have been known to put all sorts of crazy things in there (maybe an unsigned version)
Check typeof(Session["CMSID"]) and see what you get. And if it is a string go kill yourself.
|
|
|
|
|
|
Value isn't a type. Check the type. Use the typeof operator.
|
|
|
|
|
Strictly speaking, you don't need to do the conversion against Value as it's an object, so it could contain anything you like.
|
|
|
|
|
When I do a Session["CMSID"].GetType() - I get it as System.UInt32.
I tried to cast as same and it still comes back with error.
|
|
|
|
|
But, you don't need to perform any cast. You're putting it into an object, so there's no need to perform the cast in the first place.
|
|
|
|
|
Post the code where Session["CMSID"] is initialized.
|
|
|
|
|
It is requesting from querystring.
Session["CMSID"] = Request.QueryString["CMSID"];
In the database it is set up as BIGINT datatype.
|
|
|
|
|
Try this:
enteredBy.Value = Session["CMSID"];
|
|
|
|
|
Same error message - Arithmetic overflow error converting expression to data type int.
Thanks for helping!
|
|
|
|
|
enteredBy.Value = ((Int64)((UInt32)Session["CMSID"]));
Maybe?
|
|
|
|
|
Specified cast is not valid. - the message I am getting.
|
|
|
|
|
And what happens if you just use:
enteredBy = Session["CMSID"];
|
|
|
|
|
Is there a difference between string and String?
I have read on the web that there is no difference.
If there is no difference then why is one with small s and the other with capital S ?
Thanks
|
|
|
|
|
The String is actually the class System.String. It is the class that works on strings in .NET no matter what language you use. The string is the C# alias that corresponds to the System.String class. So, they're essentially the same.
|
|
|
|
|
There is no difference between them - string is an alias for System.String, in the same way that int is an alias for System.Int32. There have been various theories over the years as to why they have aliases, but I suspect the answer lies simply with the fact that things like string or int look more like their old C/C++ counterparts than String or Int32 which look very VB.
|
|
|
|
|
Pete O'Hanlon wrote: I suspect the answer lies simply with the fact that things like string or int look more like their old C/C++ counterparts than String or Int32 which look very VB.
I think it has more to do with the evolution of 'short/int/long' in C and less to due with making it look like another language. C has a tendency to keep the size of its integers in line with the common CPU register size. Some C programs are created with the assumptions that these won't change, and errors can crop up as a result of these types expanding in size. There's an article at Gamasutra about these errors (C/C++ based article, so brace for pointers and address arithmetic).
By aliasing the native type to System.Int32 (or potentially Int64 in the future), you can use 'int' for general purpose integers that fit nicely into registers where the bit size isn't relevant. Using Int16/Int32/Int64 will still give you control over the specific sizes where it might be required. A lot of C/C++ compilers have started doing something similar by creating non-standard typedefs of __int16, __int32, and __int64 to give the programmer more explicit control of their data type sizes.
Of course, as you said, this is all theory and speculation on my part.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
