|
Have you checked that the assembly is listed in the environment PATH statement? I don't know that this is necessary anymore, but it used to be a common problem. Alternatively, since this is reported as a File Not FOund error, perhaps you can try reinstalling the library to correct any registry ommisions.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
Take a look at an IOC container such as Windsor.
|
|
|
|
|
I've spent the past week chasing hints on MSDN toward some answer that I can use, and think I've finally found something that might work. Since this is my first app written in C# using Visual Studio I'm hopelessly lost already, and hope that you experts will be gentle...
The app's purpose is to manage information about installed and inventory components of an electrical substation. There are three components for now. Any of these can be moved to/from inventory and substations; they can be moved among circuits within a single substation; they have operation counters that must be recorded regularly; and they all require periodic testing and service.
What I've done so far is to gather all the existing paper information into an Access database. I know, it sucks, but there aren't many items and it's what we all have at work on our PCs. The last thing I want to do is use Access to develop an app to manage this stuff, so I thought it would be an ideal project to motivate me to finally dive into .Net and C# and learn it.
I've built an app UI with an opening Form containing buttons to open up a chain of events - Record Readings, Record Service, Move Equipment, and Inventory. My thought was to load subsidiary forms on each button click, then walk the user through the steps for each action using a series of new forms for each step and culminating in a database update query. I thought it would be simple; silly me...
So far what I've gleaned from MSDN is that I need to instantiate the starting form for each series in the On_Click method for its parent button, then use Show/Hide to render subsequent forms active and visible. Along the way, each form will have to instantiate the next in the series, and each form will have to include code to Close the previous form. Am I on the right track here? Or am I as totally confused as I feel?
All of the documentation on MSDN assumes a single Form for an app, except for MDI applications, which I do not want to use, so there aren't a lot of clues there. I'd rather not use dialog boxes because the intended users are very simple and need a consistent appearance on every page. I've derived all the forms from the opening form so that they all look identical except for the arrangement of controls in the body of the form, and I'd like to maintain that consistency.
Thanks for your guidance, and if you could recommend a really good book for learning this sort of thing, I'd really appreciate it.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
Roger Wright wrote: Thanks for your guidance, and if you could recommend a really good book for learning this sort of thing, I'd really appreciate it.
Probably not. A wide range of knowledge is brought into scope with a real project such as this. While there are sample applications that use databases, they only depict one approach (the one used in the sample ). That approach, while workable is not necessarily optimal or advisable for a production product.
For example:
Roger Wright wrote: My thought was to load subsidiary forms on each button click
Rather than have multiple forms you can use a window to display different views of the data. This is generally more user friendly.
As I stated that is only one example, moving on.
Roger Wright wrote: into an Access database. I know, it sucks, but there aren't many items and it's what we all have at work on our PCs.
I strongly advise you NOT to use Access. Take a look at SQL Server Express. There is a 2008[^] and 2005 version.
Roger Wright wrote: if you could recommend a really good book for learning this sort of thing, I'd really appreciate it.
As I stated earlier "this sort of thing" is a large scope of topics so probably not. Some of the topics might be covered in the SQL Server 2005 Sample Applications[^]
led mike
|
|
|
|
|
Thanks for the info! 
Actually, the database part is likely to be the easy part. For me the stumbling block has always been the GUI, and getting the navigation to work, variables passed back and forth, and so on. My experience trying to program for Windows has been uniformly abysmal - the documentation sucks, the example code is specious or incorrect, and the models don't resemble the real world apps I need to build. So I've always had to resort to doing a console app to get the job done. I'd like to be done with that, and that's the sort of book I'm trying to find.
I'll look into SQL Server Express, but I've already built the database using the only tools we have at work, including stuffing years of data into it. Maybe I can find a migration tool to handle that for me. I know some earlier versions of Access came with an Upgrade tool to migrate .mdbs to SQL Server; there's certain to be one like it still.
Thanks, again!
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
Roger Wright wrote: So far what I've gleaned from MSDN is that I need to instantiate the starting form for each series in the On_Click method for its parent button, then use Show/Hide to render subsequent forms active and visible. Along the way, each form will have to instantiate the next in the series, and each form will have to include code to Close the previous form. Am I on the right track here? Or am I as totally confused as I feel?
As the previous poster mentioned, I would try to get everything in one window and just display the new controls for each step. To do this, you could create a container form then create several UserControls corresponding to the steps in the process. On the container form, you could include Next/Previous type buttons that when clicked, determine where the user is and which UserControl to bring up next. Most likely, you will have a panel of some sort that will hold the current UserControl.
You could create all the UserControls and startup and simply change the Visible property to show and hide the current control, but this would significantly increase load time. You will be better off to create each UserControl when you need it and destroy it when moving to the next one.
If you can use WPF (.NET 3.0), that could simplify the process. WPF has specific infrastructure to create wizard-like applications similar to what you are describing (look for Pages instead of Window).
|
|
|
|
|
I wish I ha a clue how to do that. All I know how to do so far is make forms and stick controls on them. I probably could create all the controls and enable/disable them at run time, but trying to lay that out would be hell. WPF sounds like it might work... back to MSDN for another week. 
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
Roger Wright wrote: All I know how to do so far is make forms and stick controls on them.
My first CIS course was called "Programming Logic and Design". No languages, no compilers and certainly no drag and drop form building. I say this because down through the years I have seen a great number of wannabe programmers that thought they were on their way, because a tool allowed them to drag and drop controls onto forms at design time, who could never find their ass with two hands and flashlight.
From my perspective it seems that people starting out doing drag and drop forms development get into a lot of trouble because they tend to skip over all the fundamentals. This leaves them in the dark, always lacking valuable knowledge when trying to learn and understand a new topic.
I recognize that most people do not accept this perspective when I present it, but you seem like a good fellow so I wanted to offer you an opportunity to come in from the dark as it were. My advice, stop, back up to the beginning, always prefer enlightenment.
Good luck
led mike
|
|
|
|
|
|
Roger Wright wrote: What's new is the damned Windows environment;
Then the same principle applies. Starting out with the drag and drop dialog designer is skipping over learning how Windows works, i.e., CreateWindow() etc. Back when I started the Petzold book[^] was the defacto learning material for Windows. I don't know if it still is but perhaps it still covers the basics of Windows.
led mike
|
|
|
|
|
It took instantiating the subsidiary forms on the main form, then creating a Show method in the same form and calling it from the Button_Click method. For some completely unobvious reason I can't call frmInventory.Show() from inside a button handler, but instead have to create a discrete method and call it from inside the button. Makes no sense at all. In the subsidiary forms I had to add this.Hide() to the Done button handler to close the form and return control to the main form.
The examples I found all showed the forms being instantiated in the Program.cs file, but doing so made them invisible to the Main form. Moving the code from Program.cs file to frmMain.cs was the first step in making the thing work.
Now to figure out how to make the subsidiary forms talk to the database... I'm sure I'll be posting again soon. 
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
Roger Wright wrote: frmInventory.Show() from
Calling Show will make the form show up as a non-modal dialog. Is that what you intended?
|
|
|
|
|
I'm not sure. What I do want is a form that looks identical in size, shape, and general layout as the main form, but with new controls for each action related to the task. Clicking on the appropriate action button will launch a series of modal dialogs to collect information, then commit the action to the database, or abandon all changes if cancelled at any point.
I'm now trying to figure out how to get info collected by the dialogs back to the calling form, then get that data into (or out of) the database. I'm still not sure how to proceed on that step. In some actions I'm going to need to use dialogs to retrieve records from the database in order to proceed to the next step, so I'm debating whether to bind the db fields to the dialog controls, or to the parent form. I haven't a clue yet which approach is easier or makes more sense.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
Hi,
While sending email using the SmtpClient() object I encounter the below error message
Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host
A small piece of info - My development Virtual Machine is in to other VLAN & the SMTP Server belongs to different.
Find below code written to send email
MailMessage mailMessage = new MailMessage();
mailMessage.From = new MailAddress("some email address...");
mailMessage.To.Add(new MailAddress("some email address..."));
mailMessage.IsBodyHtml = true;
mailMessage.Subject = "Test Mail";
mailMessage.Body = "Test Mail";
SmtpClient mSmtpClient = new SmtpClient();
mSmtpClient.Host = "SMTP IP Address";
mSmtpClient.Send(mailMessage);
Is this a network issue? Or do I need to provide the credentials as well?
Regards,
Vipul Mehta
modified on Wednesday, November 12, 2008 10:17 AM
|
|
|
|
|
You may want to see if the SMTP server you're using demands you provide credentials to use it.
|
|
|
|
|
Vipul Mehta wrote: Is this a network issue?
It may be. Is the From address in the same domain as the SMTP server? A lot of installations set the SMTP server to refuse relaying foreign addresses, that is the server will not transport any email that didn't originate in its own domain.
For instance, if I send an email from user@mydomain.com using the server smtp.yourdomain.com, if relaying is disabled on the server, my email will be rejected. This is to protect SMTP servers from being used to send spam, and is usually a good practice for most organizations.
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
OK I got a chance to talk to our network team & there was some blocking done from their side & they will make appropriate settings to nake this working.
Thakns very much for all your prompt replies
Regards,
Vipul Mehta
|
|
|
|
|
Some of you well-versed in .net will be able to laugh at me shortly.
I'm trying to get a handle on the why of .net. I understand the concept of the assemblies, CLR, etc. allows developers to use their favorite language and run on any platform supporting the CLR.
But, somewhere along the way, I picked up that one of the nice things about .net was that it merged the desktop to the web. So, I could use a control on the desktop and in a web app. Now things really get insane - I seem to recall reading that if I write a desktop app in .net, I can deploy it to the web? This seems nonsensical.
So, can anyone point me at the bigger development picture for .net? perhaps there is a document or info that addresses the development approach when using .net?
yes, I know I'm babbling....
Charlie Gilley
Will program for food...
<italic>Hurtling toward a government of the stupid, by the stupid, for the stupid we go. —Michelle Malkin
|
|
|
|
|
charlieg wrote: So, I could use a control on the desktop and in a web app
Not entirely true. You CAN write a control that works on both, but there are manny, many cases where this is just not possible because of the differing UI models desktop apps and web apps use.
charlieg wrote: Now things really get insane - I seem to recall reading that if I write a desktop app in .net, I can deploy it to the web?
It is non-sensical. You can deploy a desktop app USING the web. You can NOT run any desktop app your write AS a web application. If that was true, there wouldn't be a use for ASP.NET.
The closest you get to this is an application that has business and data layers in common and shared between a Windows Forms (Desktop) app and a Web Forms (ASP.NET) app. These technologies are mearly User Interface layers to n-teir applications that can share Business and Data layer code between them.
You may want to read up on "Smart Client" applications to see how .NET makes this easier.
|
|
|
|
|
charlieg wrote: I'm trying to get a handle on the why of .net. I understand the concept of the assemblies, CLR, etc. allows developers to use their favorite language and run on any platform supporting the CLR.
Yes. Develop in the language you want. Basiclly, the languages use a common library and data types so that objects created in one language can be used in another. Compiled versions getting written in MSIL.
charlieg wrote: Now things really get insane - I seem to recall reading that if I write a desktop app in .net, I can deploy it to the web? This seems nonsensical.
You might be getting confused with ClickOnce. ClickOnce allows .Net WinForm apps to be distributed easily over a network or web *very* easily (might be where you are getting the deployed to the web part). Depending on how the developer sets up clickOnce, the users may be forced to download the new version prior to running the app or simply notified.
Generally, ClickOnce 'setups' are apps that are simply X-copied vs apps which require customs scripts or actions during install (hence need a more powerful installer).
charlieg wrote:
So, can anyone point me at the bigger development picture for .net? perhaps there is a document or info that addresses the development approach when using .net?
You'll need to get a book or two and start digging in - simply to much material to cover.
Any suggestions, ideas, or 'constructive criticism' are always welcome.
"There's no such thing as a stupid question, only stupid people." - Mr. Garrison
|
|
|
|
|
Charlie. The other answers are good answers, but I'm going to throw one more piece of confusion into the mix. There's a form of WPF that runs in a browser called an XBAP, and it is possible to host a WPF control in Silverlight. See here[^] for an example of a desktop/web control.
|
|
|
|
|
I've been fighting this one for a couple of days. I have 2 nics, and 1 computer, the 2 nics are connected to each other (same or separate subnets).
In my C# tool I am essentially trying to send packets from one interface to the other. Seems pretty basic... The issue that I am having is the internal route tables seem to be routing, instead of allowing me to force what I need out the interface. I am using .NET sockets, and thought BINDing to the specific interface and then using the DONTROUTE socket option would do what I need. Should this work? The other option is likely to use raw sockets (spoof), but apparently winXP SP2 has canned that possibility.
|
|
|
|
|
What errors are you getting? Is any data getting through? Did you remember to use a crossover cable between the cards?
"A Journey of a Thousand Rest Stops Begins with a Single Movement"
|
|
|
|
|
I have a .Net 2.0 C# Windows Service that reads messages from a message queue (xml), transforms them using XslCompiledTransform (does some other work using XmlTextReader and MemoryStreams) and then finally inserts data into a sql server database (In a distributed COM+ transaction).
The problem is that sometimes the service crashes with the .NET Runtime 2.0 Error as source and EventId 1000.
Faulting application application.exe, version 4.2.0.0, stamp 48a93225, faulting module kernel32.dll, version 5.2.3790.4062, stamp 462643a7, debug? 0, fault address 0x0000000000027d8d.
(The machine is a has a multi-core CPU)
My initial thought was that the service tried to read or write to a stream while the system was moving data between the ram and the swap. But after some more testing, the problem occurs even with ~750-1000mb free ram)
Any ideas on how to locate and fix this problem?
|
|
|
|
|
when i try to open remote web site in vs2005 from file-->open web site at write path like
http://pt.tvtc.gov.sa the message comming
The Web server does not appear to have FrontPage Server Extensions installed
but the site can open in ftp.
please how can i solve that problem?
Ala Qunaibi
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
