Well, that's the problem I'm having... don't really know how to do it! (As I've mentioned before, I'm a novice trying to learn things the hard way...
I grabbed and sniffed various code samples here on CP and mollested Google for quite some time but to no avail...
Would you be so kind to just point me in the right direction?
Create a method in the class that takes a reference (or maybe more than one) as input parameter. These references tell the class where to draw its contents, so one of the references must be the PictureBox, or whatever control surface you are drawing onto. The method then does exactly what you have already coded in your existing t_tick method. You already have all the code, you just need to move it into the relevant places.
Thank you 1M times!
I've got it working (well... sort of...). It works BUT it works SLOWLY and it draws only 2/3 of the width of the pictureBox! Any idea?
Here's the code so far...
int SCOPE_WIDTH, SCOPE_HEIGHT; // the width and the height of the osciloscope screenint SCOPE_HORIZONTAL_CENTER, SCOPE_VERTICAL_CENTER; //center point of the screenint SCAN_POINT_X; //number of points in the line (the width of the scope)int SCAN_POINT_Y; //as above but vertical (input...)int SCAN_POINT_X_NEW;
public Osciloscope(PictureBox picture, bool Run, int Interval)
SCOPE_HEIGHT = picture.Height;
SCOPE_WIDTH = picture.Width;
TIMER_INTERVAL = Interval;
//calculate mid point if the scope
SCOPE_HORIZONTAL_CENTER = SCOPE_WIDTH / 2;
SCOPE_VERTICAL_CENTER = SCOPE_HEIGHT / 2;
SCAN_POINT_X = 1;// leftmost point on the screen (start scan)
SCAN_POINT_Y = SCOPE_VERTICAL_CENTER; //the line runs in the middle of the screen
_Image = new Bitmap(SCOPE_HEIGHT, SCOPE_WIDTH);
Timer t = new Timer();
t.Tick += new EventHandler(t_Tick);
t.Enabled = true;
t.Interval = TIMER_INTERVAL;
void t_Tick(object sender, EventArgs e)
public Bitmap DrawGraph()
g = Graphics.FromImage(_Image);
p = new Pen(Color.Green, 1f);
SCAN_POINT_Y_NEW =(int) Math.Sin(SCAN_POINT_X);
// draw the line
g.DrawLine(p, SCAN_POINT_X, SCAN_POINT_Y, SCAN_POINT_X_NEW, SCAN_POINT_Y_NEW);
SCAN_POINT_X_NEW = SCAN_POINT_X;
if (SCAN_POINT_X == SCOPE_WIDTH)
SCAN_POINT_X = 1;
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!
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.
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';DROPTABLE MyTable;--'
Which SQL sees as three separate commands:
SELECT * FROM MyTable WHERE StreetAddress = 'x';
A perfectly valid SELECT
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:
|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!