|
You call DrawGraph from your main form and then again from your timer event which is not the way to do it. The DrawGraph method should just draw all the points that belong to the graph. You should probably have a separate method that collects the points based on some external occurrence.
|
|
|
|
|
Yes, I know... silly of me... I was trying to grasp how things work and got it all messed up at the end I've downloaded a sample from (How to create a simple Radar in CSharp using Visual Studi[^]) that demonstrates basic graphic (simple radar).
The original idea was to make things work from separate class - just for the sake of learning how stuff works and how it's done. At the end I wasn't able to get it to work - the problem was that all of the drawings was done in timer and I just couldn't get it to update the pictureBox...
Anyway, thanks for reply!
Regards!
|
|
|
|
|
|
Could be 32/64 bit issue if the driver is not recognised.
|
|
|
|
|
I installed the 64 bit version
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
The error message suggests that whichever version you installed, it is looking for the other one. Either that or the installation did not work for some reason.
|
|
|
|
|
The message doesn't suggest that at all. It says it can't find it.
FYI. I tried installing both versions. Same result.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Sorry, mis-read the message. I have used both Jet and ACE and never faced this problem.
|
|
|
|
|
Maybe I should try Jet
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
|
Kevin Marois wrote: Maybe I should try Jet If MS jet is not installed, the error should say
"Microsoft.Jet.OLEDB.4.0' provider is not registered on the local machine ".
Install the MS-access runtime, the 32 bit version. It would install all the drivers you need Check your app to be 32-bit, not any-CPU.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
I reinstalled the 32 bit version and change the Platform to Any CPU and that did it.
Thanks!
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
You're welcome
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
If your Access drivers are 32-bit, your app must also be 32-bit. Because you're using the Access drivers, I'd switch the compile target to x86, not AnyCPU.
The reason your app currently works while being compiled as AnyCPU is because you have "Prefer 32-bit" enabled on the Build tab. This will run your app as 32-bit all the time, even on 64-bit Windows. If this is turned off, AnyCPU will run your app as 32-bit on 32-bit Windows and 64-bit on 64-bit Windows. This will screw with your Access drivers requirements. You cannot mix 32- and 64-bit code in the same process, so if your app is running as 64-bit, you cannot use 32-bit drivers, and the same goes for the other way around.
You must match the architecture of the Access drivers you need to your app, not to Windows. Unless you have a compelling reason to run your app as 64-bit, go back and change the compile target to x86. This will make your app 32-bit only no matter what it runs on and the 32-bit Access drivers will work all the time.
Why should you do this? Because the most popular Office installation, by far, is 32-bit, which already comes with the Access drivers installed. There's no need to install the separate drivers package. Unless, of course, your client is using the Click-To-Run version of Office, which introduces another headache for your app, necessitating installing the separate drivers pack.
|
|
|
|
|
Its just a small data conversion app.
I'm almost done writing the app I'm coverting the data for, so this is fine.
Thanks
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Seems the easier approach would be to import Access tables directly into Sql Server using an "import" task in management studio. It creates the necessary tables.
Your "data conversion app" can then target the imported SQL Server tables without mucking with Access (offline).
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
If I were just getting started I would agree. This import process app has been around a bit and does some manipulation along the way. It would be a real PITA to change direction now.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
con.Open()
cmd.CommandType = CommandType.Text;
cmd.CommandText = "insert into Eleve values('" + TextBox5.Text + "','" + TextBox1.Text + "','" + TextBox2.Text + "','" + TextBox3.Text + "','" + TextBox4.Text + "','" + ComboBox1.Text + "','" + ComboBox2.Text + "','" + v + "','" + et + "','" + ComboBox5.Text + "','" + ComboBox6.Text + "')"
cmd.Connection = con
cmd.ExecuteNonQuery()
con.Close()
MessageBox.Show("l'enregistrement a reussi")
TextBox1.Text = ""
TextBox2.Text = ""
TextBox3.Text = ""
TextBox4.Text = ""
ComboBox1.Text = ""
ComboBox2.Text = ""
ComboBox3.Text = ""
ComboBox4.Text = ""
ComboBox5.Text = ""
ComboBox6.Text = ""
'Catch ex As Exception
'End Try
|
|
|
|
|
I think you forgot to ask a question.
|
|
|
|
|
Don't do it like that!
Never concatenate strings to build a SQL command. It leaves you wide open to accidental or deliberate SQL Injection attack which can destroy your entire database. Always use Parameterized queries instead.
When you concatenate strings, you cause problems because SQL receives commands like:
SELECT * FROM MyTable WHERE StreetAddress = 'Baker's Wood' The quote the user added terminates the string as far as SQL is concerned and you get problems. But it could be worse. If I come along and type this instead: "x';DROP TABLE MyTable;--" Then SQL receives a very different command:
SELECT * FROM MyTable WHERE StreetAddress = 'x';DROP TABLE MyTable; Which SQL sees as three separate commands:
SELECT * FROM MyTable WHERE StreetAddress = 'x'; A perfectly valid SELECT
DROP TABLE MyTable; A perfectly valid "delete the table" command
And everything else is a comment.
So it does: selects any matching rows, deletes the table from the DB, and ignores anything else.
So ALWAYS use parameterized queries! Or be prepared to restore your DB from backup frequently. You do take backups regularly, don't you?
Fix that throughout your app and your problem will likely go away at the same time.
But ... that code won't even compile - You've grabbed some VB code and dumped it into a C# app and just hoped like heck that adding a single semicolon will make it work. It won't: "'" is the VB comment marker, "//" is the C#, every line needs a semicolon to terminate it, and the VB was written by an idiot.
Always list the columns you want to INSERT into:
INSERT INTO myTable (myColumn1, myColumn2) VALUES (@C1, @C2) |If you don't, then SQL tries to insert them in the current table order, which means two things:
1) If the table order changes, your DB gets corrupted and that gets very difficult to fix quickly, but isn't generally spotted for a while - so by the time you get round to uncorrupting it, it's too badly mixed to be automatically fixed.
2) If you have an IDENTITY field for the Row ID, the INSERT will fail as SQL won;t let you write into it.
Even if it's currently "commented out", an empty catch block is nasty - it's a VB programmer way to not get error messages, so you don't realize that you've got a problem until it's too late. Always report or log errors so you can see what happened when teh problem become so noticeable that you have to fix them ...
Do yourself a favour, and stop using Visual Studio default names for everything - you may remember that "TextBox8" is the mobile number today, but when you have to modify it in three weeks time, will you then? Use descriptive names - "tbMobileNo" for example - and your code becomes easier to read, more self documenting, easier to maintain - and surprisingly quicker to code because Intellisense can get to to "tbMobile" in three keystrokes, where "TextBox8" takes thinking about and 8 keystrokes...
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
OriginalGriff wrote: and the VB was written by an idiot.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Eddy Vluggen wrote: OriginalGriff wrote: and the VB was written by an idiot. I thought that was the default case.
|
|
|
|
|
That was a fantastic reply. Well done
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
How would you write a code where you asked to write a code using Luhn Algorithm
with the numbers 49927398716 using two methods .The first method will be called GenerateCheckDigit;A method to generate a checkdigit, and the other method is called ValidationNumber; A method to confirm whether a give number is valid by making use of Luhn algorithm
Please help me
Thank you in advance
|
|
|
|
|
I would start by researching the Luhn algorithm itself. There must be good resources online that describe the algorithm, possibly with pseudo-code. Once I had that, I would pull together an initial implementation; using known-good outputs to validate my implementation against.
What code do you currently have and where are you stuck?
|
|
|
|