|
I have a property that return bool value.
And the corresponding data type of field in table of this property is bit type.
When I want to save this bool type property it gives the error due to the data which i am going to save in database that's data type is bit type.
My question is how to convert the property into bit from bool?
with regards
tarak
|
|
|
|
|
You can use the system convert functions. I would assume 0 <-> false and 1 <-> true
|
|
|
|
|
While passing values to a bit parameter of an SQL Stored Procedure, use 0 for false and 1 for True.
|
|
|
|
|
If you have correctly defined your parameter objects they will translate bool to bit and bit to bool automaticaly.
What is the .net code you have used to make the database call?
|
|
|
|
|
I want to execute some code on a regular 25kHz interval. It needs to be fairly accurate to within 5%. Does anyone know how to do this. I don't care what language.
|
|
|
|
|
|
I am trying to make a stepper controller. Several Windows CNC controllers, logic analyzers and oscilloscope type program allow you to choose an update rate. They are in the 25kHz - 100kHz rate. I was wondering how they do this?
There is this article Stopwatch - a High-Resolution code timer class[^] but I don't know how you could use this to control the rate.
|
|
|
|
|
You can't do that [ADDED] in a meaningful way [/ADDED] with a [ADDED] Windows [/ADDED] PC. At best it will work some of the time; and when the net result is a physical motion it will be really dangerous for people or animals in the vicinity.
The proper way to do that is to have external logic that generates the required steps, and takes higher-level commands from the PC, at a much lower frequency. So the PC could say move to X,Y using a ramp up, a maximum speed and a ramp down, and the external logic would do all that autonomously in a couple of seconds. The safety precautions (micro-switches aborting a motion when a safety limit gets crossed] should also work inside the external logic, without any PC intervention at all.
modified on Sunday, November 29, 2009 2:42 PM
|
|
|
|
|
Luc Pattyn wrote: You can't do that with a PC
And why not? AFAIK only Windows is at fault here, in DOS you could just steal the whole machine for yourself (disable interrupts etc)
|
|
|
|
|
Sure, my statement could use some refinement; if you're willing to use all of a PC's hardware then you can do it; I could even do it with Windows, except the users won't be happy with it any more; just install a highest priority driver and let everything else come to a standstill.
However it does not make sense, you need external hardware anyway (a H-bridge, a power supply, ...), so why not do it the proper way and include a little micro-controller?
|
|
|
|
|
True, true, I was just being a pedantic bitch
|
|
|
|
|
Nope. You were right, my statement wasn't correct, I've fixed it. Thanks.
|
|
|
|
|
harold aptroot wrote: AFAIK only Windows is at fault here
Windows is a shared system, not only between users, but between apps as well. Shutting off interrupts just isn't possible. You simply cannot execute code on a fixed schedule at that rate and accuracy.
harold aptroot wrote: in DOS you could just steal the whole machine for yourself (disable interrupts etc)
DOS DOES steal the entire machine for itself, and (on the surface) only does one thing at a time.
|
|
|
|
|
Why does it sound like you're arguing when you're agreeing with me?
|
|
|
|
|
isn't that exactly what you did earlier in this thread? 
|
|
|
|
|
 I guess it is
|
|
|
|
|
I just got a new job doing (gak!) VB, and I'm going through the existing code base trying to get my bearings. I've run across something that I'm not sure I agree with.
They have a class which has a property that contains about 60 lines of code, and this code runs through some financial calculations to come up with a value that is returned. I guess one good thing is that no methods or data is accessed that exists outside this class.
I've always been of the opinion that a property shouldn't perform anything more than simple get/set functionality, and extra processing should be handled in a method. Indeed, I've been bitten by this in the past, so I take extreme steps to avoid it now.
What do you guys think?
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001
|
|
|
|
|
I haven't done such things myself, and I wouldn't do it.
Most often a getter simply returns a private data member's value, whereas a setter may be more complex, as it may have to update the internal state of the entire object, not just the one corresponding data member.
A calculation deserves a method. However IMO it is just a matter of style, I know of no technical reason to prefer a method over a getter property.
And that would be the same in most .NET languages...
|
|
|
|
|
Luc Pattyn wrote: I know of no technical reason to prefer a method over a getter property.
Not a technical, but empirical; a method would imply an action of some sort, to retrieve a value. A property would imply that there's a value to be read.
I are Troll 
|
|
|
|
|
Yes, I agree, to me a getter typically returns the value of an internal variable, however there isn't a hard border line for me. I would not mind getting property "Area" for a Rectangle object (even if setting Area wouldn't make sense); and I would try and avoid database accesses in a property. Having a method name with a verb in there should indicate real actions, whereas property names are supposed to be nouns, without verb part.
|
|
|
|
|
I disagree, I don't have any problem with code for a property. I think of properties of a class as a 'logical' view to it, that is more or less independent of the actual implementation. Where I have to agree with you is that this raises the question if a property is 'physical' or 'logical'.
Rozis
|
|
|
|
|
I don't either - generally, but this one calls methods in the class, and as far as I'm concerned, that's a no-no because it could throw an exception. IMHO, setting/getting properties should NOT be able to throw exceptions because they should always contain valid data.
.45 ACP - because shooting twice is just silly
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001
|
|
|
|
|
I would agree; keep the property simple.
You are dealing with VB, I'm sure you will find much worse coding.
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
John Simmons / outlaw programmer wrote: property that contains about 60 lines of code...
...must be changed to method. That is what I would have done. Apart from little bit code like increment/decrement or any conversion/casting if needed, I never write anything in properties.
50-50-90 rule: Anytime I have a 50-50 chance of getting something right, there's a 90% probability I'll get it wrong...!!
|
|
|
|
|
You want interface as lean as possible. If you need additional functions than they should be private functions in VB or static functions in your source files in C/C++. 60 lines is not that large of a function.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
