Nerseus

If you have a reference to the openened form, just call Focus and/or BringToFront. -Nerseus

I would use the Visible property, if you really need to hide the button. Show and Hide is generally for a form. Does the button need to toggle while the form is open, or will it always be visible/invisible for each instance of the form? For example, suppose you have a checkbox that toggles whether the button is visible or not. I would NOT change the visible property in this case but instead use the Enabled property. If your are doing something in the Load event that determines whether the user has the button, then use the Visible property since you'll never want them to have access to the button. What you don't want is to have the button disappearing and reappearing. You don't really want ANY controls to appear/disappear on the fly. This is only acceptable for menus and generally only in MDI where the MDI form's menu may change in relation to the current child. -Nerseus

When telling my friends at work about buying a new home, I said I was "upgrading" :) I'm such a nerd... :) I know this isn't a question, but thought I'd share my random thought anyway. -Nerseus

There are many books on the "right" way to design. They're usually geared towards larger projects so they may not be appropriate for ALL projects, especially smaller, single form type of applications. If you're developing for a client, it's good to start with a screenshot so that you can discuss what will have to be included. It's not important to have the layout exactly right and there's usually NO code. It's just a point of reference when building up a functional spec, which includes exactly what the program (or a form, or even just a tab on a form) will do, will show, will save or not save, etc. From that spec you can write your objects, or at least start designing them from a high level. After that, you can go in start writing code. We usually have a junior level programmer do the GUI since it's mostly renaming controls, adding events, etc. The more senior developers code the components, web services, DataSet schemas, etc. When the junior's get done, the seniors do code reviews to make sure the juniors didn't do anything crazy :) On smaller projects, I still start with a basic GUI. I may or may not rename controls in the beginning. I hate spending 20 minutes renaming them and then deleting half or moving them around or whatever - I hate that rework. Once I have the screenshot close to what I want, then I can stub out code. For me, that means creating functions (minus any code) with comments to let me know what each function will do. Each is marked with "// TODO" which in C# shows up in the Task List, so that I can easily go back and put all the code in. -Nerseus

What level of school are you, SDittmar? In the US they cover Trig somewhere between 8th and 10th grade, usually (if I remember right). If you haven't gotten that far yet, you may have a tough time picking it up - but feel to go to your librarian and ask for a book. Many graphics, unfortunately, either don't cover the basics very well or go into pure-formula mode. I'd stick with a math book for now, to pick up the basics of Cos, Sin, Tan, etc. -nerseus

Take a look at this thread -nerseus PS Don't forget to use the help files that ship with Visual Studio - they have a ton of help and samples and give you the specifics of each object.

Check out the tutorial on regular expression matching. You can define a regular expression that matches your string and use the Matches object to get each piece handed to you (First, Middle and Last). -Nerseus

Did you know that offhand, or did you go searching for it Robby? :) Either way, I'm impressed. -Nerseus

Do you HAVE to have it on the ASPX page? Normally it's a good idea to let SQL Server create the GUID if you're talking about inserting into a uniqueidentifier column. I've had to create them in VB6 because I needed the GUID to insert into multiple, joined tables. If you just need a GUID for another reason and want to insert it into a table just for storage, then someone else will have to help. -nerseus

Ah, contractors - we call them "short timers" :) Just kidding, Robby. Contractors can be a great thing if used correctly (and if they know what they're doing, as I'm sure Robby does). Contracting is great for the young and old (and always for the pocketbook). Us in the middle need/want more stability. -nerseus

Do you need the GUID client side or can you let SQL Server create it? I think it's something like this (might be off and I don't have SQL server here): DECLARE @GUID AS uniqueidentifier SELECT @GUID = new GUID I don't know how to get one in VB.NET... -nerseus

I love doing GUI. I don't spend nearly the time "toying" anymore - I let others figure it out then do it all at once. Well, first I design the GUI, sans any code. I bring screenshots of this to meetings so that our analysts can see what the screens might look like. That helps flush out any problems early on, and before I've spent too much designing a screen the way *I* think it should work. I'm over my "I know better than you" attitude -- the analysts are going to change them 10 times, then the real users are going to change them 10 more. I wait til they get at least 5 or 10 changes queued up before I go back and do any tweaking. In the meantime, the specs are being finished and I can start designing the code (defining whatever it needs to get written before I start writing it). Then I code it. It doesn't sound as fun as sitting down and making a GUI and adding code, but it saves a ton of time later. -nerseus

I've switched every few years for the last 8 or 9 years. I'm on my 4th main job, though I did some consulting in between. Each time I moved it wasn't because I was unhappy but because something else came up - I've always been careful to choose the place I work at. Meaning, when you interview, it's a two-way process: they're not JUST going after you, but you need to decide if you like them. I helped start the company I'm at now and I love it. I've worked with most everyone for at least 3 years now, some almost 6 years. We're all really good guys, love programming, etc. etc. Since I love the work and the pay is good I wouldn't even consider switching. On the other hand, there could be a number of reasons for someone to switch. Switching can often mean higher pay, especially in your first few years programming. You learn the most during this time and your current employer may not be willing to boost your pay accordingly. But if you're really happy, it may not matter as much - I'd rather enjoy what I was doing and make a few grand less than work with people or on projects that I didn't like. If you switch TOO often, it looks bad on your resume. Unless you're a consultant, many employers don't want to see you switching every six months or a year. It takes at least 3 months to get settled in at a company and they'll spend the next 6 months or so making up the money they spent training you and getting you settled before they start making money off of you. If you leave too soon, it will hurt them. Then again, you may be at a company that you like and working with people that you like and even making good money, but the work itself isn't that satisfying. Maybe you're just supporting an old app and not doing any "fun" or "new" programming. If you're aching to advance, your only chance might be to switch, even if you don't want to. My first job was like that - doing VB3 programming on a large application (100+ forms, each hitting the Windows limits for the number of controls per form, etc. etc.). It was GREAT experience at learning VB, Windows, DataBases, etc. etc. I loved the guys I worked with, I got to go to conferences for free, training was free, good salary and bonuses and lots of raises (about 6% every six months - I advanced quickly). But in the end, after about 2.5 years I was just getting bored. The work was too easy and my boss didn't want to find any new contracts or hire any new people. I felt *really* bad when I left since I didn't have any bad feelings. But I knew if I stayed, I'd be doing VB3 for another 5 or 10 years just supporting that app. Making a move worked out great for me, but it might not be right for everyone. Anyway, that's my long ramble for the night :) -nerseus

*whew* again :) -nerseus

You can use DISTINCT pretty much anywhere, including inner and outer joins and you should be able to do it across databases. Can you post your SQL so we can take a look - much easier to debug it if I can see it. Also, where is the query "at"? In access with a link table to SQL Server, or is there a remote server in SQL Server that points to Access (not even sure if this is possible)? -nerseus

Suppose you have a scenario where User A gets a row of data and begins editing. Then User B gets the same row, edits it, and saves it. Do you want to: 1. Not even allow User B to edit the row 2. Have User A (who is updating second) overwrite User B's changes 3. Give User A a message that they can't update since someone's changed the data since they first looked at it 4. Notify User A immediately when User B saves. Here's some ways to handle these cases: 1. Access doesn't suppor row level locking. SQL Server does, but you'll need to enable the row-level locking. You'll probably need some kind of custom row-locking: the basic idea is to set a flag on a row when editing begins. You must worry about cleanup if the user who holds the lock crashes and the lock is still held - this is never fun to implement, but sometimes necessary. 2. This is the most common scenario and easiest to implement since you don't have to do *anything* :) 3. This requires keeping a date or something other date/time stamp when you begin editing a row. When you go to update, check that the date in the database matches your date. If they don't match, someone else has already updated your row. You'll have to decide if the second user is out of luck or if you try to do some kind of merge (or use Number 2 and just overwrite anyway, after a message). 4. This is pretty much impossible so don't worry about it :) -nerseus

I can't duplicate this unless I change my taskbar to NOT stay on top. Can you show us the code you're using? -nerseus

The Forms collection from VB6 is no longer available. As wyrd mentioned, an MDI form knows about it's children, but looping through them all is not the .NET way - I'd go with divil's and dynamic_sysop's suggestions. -Nerseus

You need a space between TABLE and the name of the table. Right now, the double quote is next to the word TABLE. Try this instead: Dim oledbcom as New oledb.oledbcommand=("CREATE TABLE " & lblinstructor.text &... -Ner

What I've usually seen is that not ALL the code in InitializeComponent is gone, just the few lines that reference the current form (Me in VB.NET or this in C#). In particular, the line that adds all the control to the form (sonething like this.Controls.AddRange(...)) is missing. Without this line, .NET won't know to add the controls to the form. So even though all other code is there, including creating controls, the form won't render any of them. -Ner

Are you allowing more than one row to be updated at a time? If just one row at a time, are you saying you want to lock that row until the first user is done with it? As I said, if you are only allowing one row to be modified at a time, the database will guarantee that each UPDATE will succeed. If they happen at the *exact* same time, Access will allow one update to occur, then process the next one - last one to update wins. There's no built-in way around this - you'd have to code something to prevent it, but I need the specifics of what you want before I can offer any advice. -ner

You may have to do manually looping to do this. You could try something like: Dim i As Long For i = 0 To SalesRep1.Tables("sales_representative").Rows.Count - 1 If (SalesRep1.Tables("sales_representative").Rows(i)("ID").ToSTring() = searchtxt.Text) Then gridControl1.Select(i) End If Next I'm not sure how you select a row in the grid offhand, but I think it's just Select (might be SelectRow?). -nerseus

Ok, here goes (may not work exactly right): Public Class mainClass Private device As Device public Sub New() ' This class's constructor, create the device device = New Device(...) ' Create class 2, passing in the device Dim c As Class2 = New Class2(device) End Sub End Class And the second class... Public Class Class2 Private myDev As Device Public Sub New(ByRef dev As Device) Me.myDev = dev End Sub Private Sub UseDevice() 'You can use myDev here... End Sub End Class -nerseus

DataSets are disconnected. They have NO concept of a connection, SQL syntax, source database or anything else. You can test it by creating a DataSet in code, adding tables, columns, relationships, and everything. If you want to fill a DataSet from a database you must use a DataAdapter, which has a Fill method that fills up a DataSet. Likewise, to update a database you use the DataAdpater's Update method (or execute INSERT, UPDATE and DELETE SQL commands through a command object). -nerseus

Ah, I think you have to use the New() function in VB.NET. The default constructor takes no params, so you end up with New(). You can change that to New(ByRef dev As Device) I think - not 100% about VB.NET :) -nerseus