Nerseus

For my XSD's, I use the following schema line, more or less (note the xmlns is just an empty string). The targetNamespace is removed as it generally causes trouble (can't remember why - we started removing them almost 2 years ago and it's been our "standard") <xs:schema id="name" elementFormDefault="qualified" attributeFormDefault="qualified" xmlns="" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:msdata="urn:schemas-microsoft-com:xml-msdata"> -Ner

I've only done this when including files - I've never tried an "include" if it's memory based (reading an XML string). In my XSL file I have: <xs:include schemaLocation="../../../schema/customtypes.xsl"></xs:include> In this case, the customtypes.xsl file lives "up" 3 folders and then "down" in the "schema" folder. It works fine for me. I would guess that if the customtypes.xsl file were in the same folder just using the following would work: <xs:include schemaLocation="customtypes.xsl"></xs:include> -Nerseus

You might look into using SQL Server's Data Transformation Services (DTS). If you have SQL Server Enterprise Manager, expand "Data Transformation Services". If your goal is to import data from some datasource (like FoxPro or DBIV or whatever - even Excel) into SQL Server, then DTS is probably the way to go. Start by right clicking the DTS "folder" in Enterprise Manager and selecting All Tasks->Import Data. You can pick your source (FoxPro) and destination (this SQL Server or another database - Access if you want). You can tweak the fields being copied and apply a script to each copied row. For example, say you have a "Name" field in your FoxPro database and you want to split that into "First", "Middle" and "Last" fields in SQL Server. The custom script allows you to use VBScript or Javascript (Maybe more, haven't done this in awhile) to tweak whatever data you want. As a default, the script will look something like: source["Field1"] = dest["Field1"] source["Field2"] = dest["Field2"] source["Field3"] = dest["Field3"] You could tweak it something like: Dim first as String Dim pos as Long pos = InStr(source["Field1"], " ") first = SubString(source["Field1"], 1, pos) dest["First"] = first source["Field2"] = dest["Field2"] source["Field3"] = dest["Field3"] You get the idea, hopefully... -nerseus

I thought I heard there's support for XQuery in Whidbey (the next Visual Studio / .NET). I can't say I've seen it in .NET 2003. I might be confusing XQuery and Whidbey with the next SQL Server, which I believe has much better support for querying against XML (just better XPath support). Then again I might just be confused. -nerseus

Here are two threads that may work for you (sorry I didn't have these last night - too late for me to do anything helpful). http://xtremedotnettalk.com/showthread.php?t=69218&highlight=browser+event http://www.xtremedotnettalk.com/showthread.php?s=&threadid=69047 -Nerseus

IDE's can help in many ways. Visual Studio does put a LOT of stuff into the IDE, including the ability to manage servers (Databases, Event Logs, etc.). If you're evaluating what IDE's have, it could be a LONG list. The simple text editing features alone could cover a few pages. Integration with other tools - either automatically or through "Add-Ins" - could be another few pages. Is this for school or just for you to compare what YOU might like? If it's a specific set of features you're looking for, I'd concentrate on those. What I mean is, if you're "just" programming, look for an IDE that has a lot of text editing/searching features. If you're looking to list out the importance of an IDE in a business environment, then you'd concentrate more on the integration with a "business" developer (database integration, server integration, etc.). Some IDEs only handle windows programming while others only do Web. Some are, more or less, specific to a language or two while others are mainly JUST text editors with some config files to make it look like an "IDE". If you include those "text editors", the list could get big quick. Look at UltraEdit, TextEdit, MultiEdit, JEdit, and more - they all can do programming (compiling), integration with source control tools, and more. -nerseus

Depending on the type of demo, maybe you could "prime" the app on the demo machines before the end users do their testing? Or if it's a bigger release, you could let your implementation team know the details and pass that along. A good explanation may go a long way, especially if they hear that the app is optimizing itself the first time through so be patient, and they'll get the rewards from then on. -Nerseus

I know you can interact with the WebBrowser control. There was a "trick" posted here a few months ago (maybe 6-12 months ago even). I know divil was involved in the thread, so you may try searching some old posts, especially using the name of the control (axwebbrowser or whatever it is). The idea was to get a .NET object that represents the Document object of the current page (I think). You could then interact with the page, receiving events and setting properties - at least, that's what I vaguely remember about the topic. Vague? Ah well, it's Saturday and I've 40 more hours of work to do in 2.5 days :) -Nerseus

You've got a function returning a table. As far as I know, you can't return the results of the EXEC call as that table. Meaning, if your proc does a "SELECT...", you cannot return the results of that select from a function. To use the EXEC statement in a function, you would normally do this on a proc that has an output parameter or returns a value. For example: DECLARE @result int EXEC @result = myproc @param1, @param2 or DECLARE @result int EXEC myproc @param1, @result output (I can't remember if you need parenthesis around params in an EXEC call) Maybe if you explained what you're trying to do...? For example, why must you use a function to return a table? Why are you calling a system proc within the function, etc.? -ner

I don't know that ClassName they use. I know in VB6 (and under) days all windows had the same classname, ThunderForm or something similar (hold over from VB1 days if I remember). A Spy tool should be able to show you the classname, to determine if it's a common name like "DotNet" or the class's name "frmMain". If the DLL is yours, why not change its interface to receive the handle to the window you want to hook into? -ner

When you add a reference through Visual Studio, the default dialog shows all DLLs in the GAC - it should show your Assembly there. If not, something might have gone wrong. By the way, save that strong key in a safe place. We often include the key in the project (with Build type of "None") so that it can get saved to SourceSafe (which we backup every night). Most of the intellisense will work (with any dll) - meaning, declaring "MyObject o = new ..." will show you a list of objects, including "MyObject" from the project. If you mean the descriptions that go under the method names (and for each parameter), I'm not quite sure. I haven't tried that. Some added info: I generally do NOT use the GAC for "common" DLLs. Instead, I keep them up on a network share that all developers can access. It simplifies the change process since a new DLL doesn't have to be copied to everyone's machine and updated with a new version number. Instead, the DLL is copied to the network and everyone automatically "sees" it when they rebuild their solution. -Nerseus

My company uses a 2 EXE approach. One exe, the "loader", runs and shows a splash screen/progress bar. It reads from a config file and "downloads" DLL's, EXE's, etc. (checks versions and more) then launches the main EXE (which may show it's own splash screen, but generally shows a login box first). The "loader" can even download a new loader if needed (don't ask me how - I didn't code it!). I assume you're trying to show something while your app is "loading" but before any code has run. This is just one approach, but a simple splash screen inside your app may work well, too. -ner

What's your output going to be? A grid, a printed report, something else? Are you asking how to loop through the array, do the formatting, or how to get a formatted string into something viewable? Let's say you had an array of strings (names) that you wanted to format and put in a textbox (simple code): string[] mynames = new string[] {"Dan", "Bob"}; textBox1.Text = string.Empty; foreach(string s in mynames) textBox1.Text += mynames + "\r\n"; If you wanted this string in a listbox: string[] mynames = new string[] {"Dan", "Bob"}; listBox1.Items.Clear(); foreach(string s in mynames) listBox1.Items.Add(s); -Nerseus

References will be copied to the bin\Debug or bin\Release folder only when "Copy Local" is set to true. This defaults to "False" for references in the GAC (such as System, System.Windows, and probably Component1). I think you can toggle the "Copy Local" to true for all your references (easy solution) or create a new Setup project and have it do the copying for you. I don't know if the "Copy Local" will get you all the dependencies or not. References in the GAC register themselves and, in doing so, mark other DLLs as references. So System.Windows has System as a dependency (as a bad example). I'm not sure if setting "Copy Local" will copy ALL the dependent DLLs to the bind folder, so you still might have problems. You can try it, but if you run into problems it might be easier to just create the Setup project. -Nerseus

With your current "solution", Kingherc, you should be able to use akiaz's suggestion and make your life a lot simpler. 1. From the solution that has your VB project, right click the solution and select "Add Existing Project" and point it to the C# project file. 2. Remove the reference to the C# DLL in your VB project. 3. Add a new reference in the VB project (right click References). Click the "Projects" tab and you should see the C# project. Assuming the C# project is still set as "Class Library", it should work fine. -Nerseus

This is an untested theory, but might work: Can you code your controls in one library with any/all "common" code. Figure out the differences between platforms (drawing, specific function calls, etc.) and wrap all of the "special" cases as an abstract class in the main project. Then implement the 3 DLLs that each implement a specific version of the abstract class for each platform. The main project decides which DLL to load. You can have it "decide" based on a compile switch as well. I use the configuration manager to create new build types. Each of the new build types can define their own conditional compilation constants (in addition to DEBUG and TRACE). Then you can do a batch build in Visual Studio to build all 3 libraries at once, each compiles with a separate constant (and hence separate code). This will NOT work for separate references currently, as Visual Studio keeps the references in the project and not through a project property (which is where you can define differences between Build types). If you depend on different references, you'll need different projects. You can handle that through sourcesafe, potentially. Sourcesafe can share files - so you can have 3 unique projects with all files being shared EXCEPT the visual studio project file. Luckily, Whidbey has moved the references into the Project Properties area, so you can define different references per Build Type. Doesn't help you much right now though :) -Nerseus

To elaborate on akiaz's comment: References marked as "Copy Local" (the default) will be recopied to your local harddrive. At my work, we keep the "common" DLLs on the network so everyone can reference them in the same location. Visual Studio does NOT recognize when these files change. A rebuild will always copy down the referenced files so that I can "see" new classes/methods when they're added. I generally use Build when I'm checking for syntax - just to make sure it compiles. I use Rebuild when I'm going to run my app (in Visual Studio) or when I want to compile and give out the DLL or EXE. Even with a large solution of 14 fairly large assemblies, a full rebuild only takes 5 or 10 seconds. -Nerseus

There are two basic ways to organize your code, depending on what view you like in Visual Studio. I prefer the Solution Explorer, which shows files and folders. For that, you can create folders in the project (which become folders on your harddrive and folders in Visual SourceSafe if you use it). New classes added to that folder will have a default namespace that includes the folder name (best to use folder names with no spaces). For example: MySolution1 - MyProject1 (the project) \UI\ - frmMain.cs - frmSplash.cs - frmMyDialog.cs \Components\ - mainain.cs - splash.cs - mydialog.cs \XSD\ - dialog.xsd In this sample, the UI folder contains the forms. I like to have each form's UI code in the form's class, but all "business" code in a separate file. I keep these "component" classes in a "Components" folder. If your project has other file types, such as typed Datasets or similar, you can make separate folders for them. You can obviously create as many folders as you like. Namespaces: In the above example, the namespace for the class "frmMain" in file frmMain.cs would likely be "MyProject1.UI.frmMain". The corresponding component class would be "MyProject1.Components.main". The new Visual Studio supports "partial" classes, which means you can split one class among many files. With partial classes it might be possible to keep the UI and "business" code in two files, but they're combined into one class when compiled. I haven't played with that too much to see how it works out. In "Class View" (as opposed to Solution Explorer), you can get a hierarchy of the classes grouped by namespace. The above structure would look very similar. Using either view, putting namespaces in your classes is a Key. The namespaces should generally follow the pattern of files on the hard drive unless there's a good reason not to. So if you have frmMain.cs in the root folder and want to move it to a "UI" or "Main" folder, you'd have to modify the code from something like: using System; namespace MyProject1 { public class frmMain { } } to something like: using System; namespace MyProject1.UI { public class frmMain { } } -Nerseus

I'm not sure what you're doing with the library, how it is planned to interact with .NET. But, in generally, I'd say you could definitely convert it, or at least re-use the library in .NET. Look for "DLLImport" on how to import the external DLL calls into your .NET application. The constants, as with Powerbasic, will have to be defined as normal constants in .NET. If your DLL just takes a handle to a window to handle things, then you can get that from a .NET window. For other issues, you'll need to ask more specific questions. -Nerseus

Compacting reduces size because Access is using the one database file as a virtual file structure. As records are added and then deleted, their old space is retained in the Database. Updates, I believe, are generally inserts and deletes (how they're handled internally) and so they leave unused space in the file where the "old" records were. A compact looks for these areas and cleans them up. You can think of a "Compact" operation as the same thing as a disk defragmenter - it cleans up unused areas and moves data around so that the "unused" stuff is at the "end" of the file, then truncates it out. More or less : As you said, that's what Programming is - if Access doesn't currently have a "Copy Database minus the Data" function, then you may have spotted a useful programming oportunity :) If you happen to have SQL Server then you can "automate" the copying of the structure by using DTS, which can copy between Access databases. An option of DTS is to only copy structures. If you have a developer license to MSDN then you can install SQL Server tools (Enterprise Manager) to do this for you. As long as you're not managing an Access database used by your company (or you), then you don't need to buy a license to SQL Server to use the tools. -Nerseus

It "works" though I would NOT want to use it for very long. Given the built-in features of .NET, you could easily write about 90% of the functionality yourself and have a MUCH nicer tool. For a developer that's familiar with DataSets and binding to a grid, you could do the rewrite in a couple of days and have a LOT more/better functionality. I'm not trying to put down the freebee tool, but you get what you pay for :) Don't forget, if you own Access you can add a linked table (point it to your MSDE database) and run queries in Access. I don't like Access' query tool very much either, but some do. And if you own Visual Studio (not sure which versions include it), you can do DB management and write queries from the Server Explorer. Just add a connection to your MSDE database and there you go! By the way, Whidbey has a lot more and WAY better support for DB functions built in! (Whidbey being the codename for Visual Studio 2005, due out next year). -Nerseus

I don't think there's anything in the standard .NET libraries for creating tables, regardless of the "source". For most databases you can execute a "CREATE TABLE ..." statement to create a table. I don't think there's anything available to do this for you. I'm SURE there are tools that do this for you - create a database from a Dataset. If you want to write it yourself and you know that your DataSets are "clean" then it wouldn't be too hard. You can easily loop through tables, relationships, and columns in a dataset and create these "CREATE TABLE..." statements yourself. By "clean" I'm referring to the fact that a DataSet may have different datatypes than your Database so you'll have to make some assumptions (fine for you, maybe not Ok if this is a more general purpose chunk of code). If your purpose is to rebuild a database, I'd wonder why you wouldn't have a backup? Seems much easier to backup an Access database (one file) or a SQL Server (2 files generally) then to backup a DataSet and have to restore from the DataSet. Plus, a "real" backup would save Queries/Stored Procedures and other niceties. -Nerseus

I don't know the API call, but I can lead you there... If you're hooking Windows to get all mouse movements/clicks (SetWindowHook or something like that) then you know the coordinates of where they clicked. There's another API call to figure out the topmost window at a given location, but I don't know what it is. We do have a policy against helping anyone asking for help that even looks suspiciously like it might be used for "evil" purposes :) Maybe you could describe the bigger picture of what you're trying to do - we might have other (and better) suggestions? -Nerseus

Original timeline: 18 months. Your timeline to re-write: 3 weeks Sounds like not a total re-write, but a strong need for Refactoring! I picked this book up a few months ago and it has been fantastic! I knew many of the techniques described, but the author's insights in the first 2 chapters are worth every penny. If you had a bit more time, then using some Design Patterns (or Design Patterns Explained) will greatly help you out. When using Design Patters and Refactoring together, you can lessen the amount of up-front planning. No more worries about getting the design exactly right the first time. You still need some planning - but you don't have to (and shouldn't!) plan for everything. -Nerseus

That is probably the best, and simplest, description of a contract - whatever both sides agree to :) If you trust your teacher well enough, you might not need a contract. If the program starts making a lot of money, just make sure you get what you hope for or write that contract now, before delivery. If it's been sold on "promise" with a contract, then the teacher (I think that's who you said is handling this deal) is responsible for delivering, not you. Things will probably work out Ok - but if they don't, you'll know for next time :) Yep. A company buying your sourcecode should know (you may have to tell them) that these "simple" libraries aren't being bought with exclusive rights - only their specific details are being bought. To keep things simple in case they argue the point, it's best to keep the "all purpose" code in a separate assembly (at least one) so you can show them what they're NOT buying the sourcecode to. I've never come across a client who said "whoa! I thought we were getting EVERYTHING". Some have asked for the source to the common library, which I've given. In general, I only deliver the DLL for those common libraries. They generally don't care about the source for the common library unless they decide to hire their own internal people to continue development. Good luck with the project. I hope you get some money from it :) For the record, my first "contract" work actually had a contract - sort of. I wrote a program to cheat at a game back in college on the request of my roommate (Masters of Orien 2 I think). He paid me in 2 pizzas, one before I started (to keep my going through the night) and one the next day when it was done :) -Nerseus