PlausiblyDamp

Firstly Port 139 is a common port for attackers to attempt access on - it's one of the MS NetBios ports (specificaly the one used for File and Print Sharing). Getting 42 attempts to access this isn't too uncommon when online for any length of time - also it looks like the firewall has done it's job (blocked and noted the attempts), so not a particular reason for concern in my opinion. Secondly is your PC called yup4 by any chance? IIS during install will create a user called IWAM_, this is used for launching processes that run outside of IIS itself. On it's own the presence of this account doesn't indicate anything untoward happening. If you bring up task manager is there any process hogging the CPU? Have you recently run a spyware removal tool - if not do so. Do you have an up to date anti-virus package installed (and are getting the updates regular), if not you really should. Thirdly running 3 firewalls on the one PC at a time could be causing problems - you should really only need to run 1, multiple firewalls will be conflicting with each other in trying to open / close ports etc - this could be causing problems with internet access and most definately cause the speed reduction. Having a backup is a good idea, doing a reformat and install may be a bit harsh though. As to why you - your on the internet. Being hacked (or attempted hacks anyway) are just part of the rich experience that is the internet ;)

Intro to OOP Part 2 Guide to Object Orientated code in .Net part 2 This post is a continuation of the one found here Introduction In the previous article we looked at how to create a simple class and saw how to then use the functionality it provided. In this article we will look at a feature that can make our coding life a little bit easier and our code a little bit cleaner. Properties One nice syntax feature .Net offers is the concept of a property � these can be accessed as if they were a simple public variable, but really are a function call. This means we get the best of both worlds � cleaner code syntax and the power of re-usable code. In the previous article we could retrieve the current balance through the GetBalance() method, this however can result in potentially ugly syntax (and in certain languages like Java is the only way of doing so): Imagine we needed to be able to set the balance without going through the Credit / Debit methods a simple concept like adding 10 to the balance would involve code like the following �First we need a function to set the balance Public Function SetBalance(ByVal newBalance As Decimal) As Decimal _Balance = newBalance End Function �to call it we end up with code like Acc.SetBalance(acc.GetBalance() +10) or //new function to set balance public decimal SetBalance(decimal newBalance) { _Balance = newBalance; } //would be called like Acc.SetBalance(acc.GetBalance()+10); Although not difficult code it can look messy and is quite hard to skim over. Properties simplify this syntax by exposing the functions in a slightly different form Public Property Balance() As Decimal Get Return _Balance End Get Set(ByVal Value As Decimal) _Balance = Value End Set End Property �would now be called like Acc.Balnce = acc.Balnce+10 public decimal Balance { get { return _Balance; } set { _Balance=value; } } //would be called like Acc.Balnce = acc.Balnce+10; Note that in the C# version the value to be assigned is implicitly passed as a parameter called value, even though this is never apparent from just looking at the code. This results in a much cleaner and easier to read syntax, one problem this has introduced is that the balance can now be modified outside of the Credit and Debit methods., this is easily fixed by removing the set portions of the code (and marking it readonly in VB) like so. Public ReadOnly Property Balance() As Decimal Get Return _Balance End Get End Property And public decimal Balance { get { return _Balance; } } Now we can only retrieve the value of the balance through this property and not assign values to it directly. Although in this case the functionality is trivial we are introducing an extra function call by using properties rather than a public variable; despite this performance issue there are three good reasons to go with properties: 1) We get compile time detection of attempts to update the value direct � these are really a breach of our business logic and shouldn�t occur. Using properties will prevent a successful compile occurring and prevent people bypassing our methods. 2) If we do a release build the Just In Time (JIT) compiler will very probably inline the call � this basically removes the function call and at runtime access the variable direct anyway (but still read-only as the compiler would have prevented any other kind of access) 3) In a more complex scenario we could do much more complex validation in the set portion of the property and reject values that do not meet our business rules and we could also perform complex calculations in the get portion � allowing us to either calculate values on the fly if the internal store is in a different format (remember the idea of a date using UTC or local time) or is physically stored elsewhere e.g. a Database. Playtime Have a look at the attached samples and see how using properties works in code Next Methods BankCS.zip BankVB.zip

Guide to Object Orientated code in .Net Introduction This is intended as a guide on the features .Net provides in terms of Object Orientated Programming. This post will cover simple issues such as classes and structures as well as basic terminology used. Later articles will cover other areas such as interfaces and inheritance. Most of the code snippets are in VB.Net but C# will be shown if major differences occur and I will endeavour to include complete projects in both languages. Within .Net everything is an object from the most complex classes you design to a simple Boolean or Integer value .Net treats everything the same. To really understand how to best take advantage of .Net getting to grips with the concepts of Object Orientated Design / Programming is a must. The first difference when coming from a non-OO (Object Orientated) language is there is no longer a separation of Data Structures and Functions that operate on those structures, both concepts are merged into the idea of an object. This introduces two common terms found in nearly all OO literature Encapsulation and Abstraction. Encapsulation is simply a term that means �hiding the implementation details�, if you wish to write useful code that can easily be used by either other developers or even yourself months from now you need to remove the requirement for the user to have intimate knowledge of the inner workings or have to depend on specific implementation details. e.g. The .Net Framework provides a System.Date class, which provides date related functionality (Add dates and times, subtract Dates and times, convert between local and UTC times amongst others) to use this class you need no knowledge of how it implements this functionality � does it store dates as a single offset from an arbitrary point in time, as a string, as a series of integers? Does it internally use UTC or local time? The point is as a developer using this class you do not need to know � and more importantly do not need to care if it�s internal implementation changes in a later revision � the only important thing is the functionality exposed by the class doesn�t change between revisions. Abstraction is the idea of taking a real world object or concept and simplifying it to the point where it is usable from a coding point of view i.e. has enough exposed functionality that it is usable, without being bogged down with irrelevant details. This can be a tricky part of the design process � getting enough functionality into a class without overloading it with irrelevant details. Simple Example To best illustrate these ideas let�s start with a simple class to model the familiar concept of a bank account. At a bare minimum all bank accounts require the ability to retrieve the current balance, add money (not often enough) and subtract money (far too often) and have an associated account number. In a non-OO language like C this would often involve a structure containing the data and several functions that act on this data e.g Struct BankAccount { public int AccountNumber, public float Balance } //stub function void Credit(BankAccount acc, float Amount) { //credit code here } and though this system works it requires developers to 1) know there is functionality to perform Credits and Debits and 2) be bothered to use them. One major potential problem is that the data members of BankAccount can be accessed without using the provided functionality � any code could modify the balance and bypass any error trapping / validation the Credit / Debit methods provided. A typical VB version of the above would look similar to Public Class BankAccount Private _Balance As Decimal Private _AccountNumber As Integer Public Sub Credit(ByVal amount As Decimal) _Balance += amount End Sub Public Sub Debit(ByVal amount As Decimal) _Balance -= amount End Sub Public Function GetBalance() As Decimal Return _Balance End Function End Class Notice the account number is ignored for now (this will be useful later) and that both it and the _Balance variable are declared Private � this means they are not visible from anywhere outside the BankAccount class, but due to the fact they are declared within the class but outside of a particular function they have what is referred to as Class Scope and can be accessed by any function within this class. We have instantly removed one potential source of bugs � if you need to modify the balance you must do it via either the Credit or Debit Method (OO name for Function, Procedure or Subroutine) which are declared as Public and as such can be accessed anywhere (we will encounter other options in a later article). Although currently our versions are lacking in any validation or error trapping these methods cannot be bypassed, and if we chose to change how the _AccountNumber or _Balance were stored then only the exposed methods would need to be updated � as long as they returned the same data type and accepted the same parameters then no calling code would need be modified. Playtime I suggest having a quick look at the attached projects and stepping through the code in a debugger � try changing some of the routines and see which pieces of the BankAccount class are accessible from the form and which bits aren�t. Next Next article we will look at properties BankCS.zip BankVB.zip

The .Net framework versions 1.0 and 1.1 don't appear to provide any classes for getting at drive information - however in the 2.0 framework there is a DriveInfo class that seems to provide the functionality you require.

Just in case nobody has come across this before http://www.roland-weigelt.de/ghostdoc/ a visual studio add-in that simplifies generation of XML documentation in C#. Really takes the tedium out of documenting obvious things like property accessors and similar.

Using an existing library like http://www.exocortex.org/3dengine/ or http://www.randyridge.com/tao/default.aspx (seems to be down at the moment) then doing 3d in opengl is no more difficult than Direct3D (a lot of the same principles apply). OpenGl also has the benefit of being (potentially cross-platform, more of a concern when the forms support in project mono matures.

Bit off topic but the way try ... catch ... finally is designed is that for a normal (i.e. no exception thrown) execution then the overheads are minimal. Exceptions being thrown / caught however do incur a noticable performance hit - then again if things are going astray performance (especially for a non-normal condition) is probably a secondary concern.

When you use wsdl.exe it puts the url of the web service into the proxy class itself.

An easier way would be to put code in the Application_Error event in the Global.asax file.

Is the browser configured to allow cookies from that domain name?

Probably find it easier to store something like a connection string in the web.config file, search these forums and you will find examples of how to do this.

Could just be settings in the browser - check what margins the browser has set for printing and how wide the page is.

and your arguments to back this up are......

My bad - teach me to post code without running it. Try this instead Dim p as new Point(imove.Location.X,imove.Location.Y+1) imove.Location=p

The first bit you are using a command, the second bit you are using a Connection - you probably meant to use a SQLCommand object.

may be worth investigating some of the links in this thread

imove.location.y=imove.location.y+1 .Equals is used for comparison not assignment.

Sorry but which bit of did you miss? You are still using an OleDbConnection - try using a SqlConnection object instead

firstly could you show the app.config file - it may make things clearer. Also not sure what you mean by are you storing connection strings anywhere other than the .con

Did you use the SQLconnection object? What errors did it give? If you are using SQL you certainly don't need the provider=Microsoft.Jet bit in there

Something like the expression posted here should give you a start

There is no easy reliable way to do this - if you want to only allow one person in at a time and then only time them out after 20 or 30 minutes you are looking at restricting your application to 2 or 3 users per hour - pretty unacceptable I would say. If the system can be updated by multiple people then there needs to be some other mechanism in place to either prevent conflicting updates or to make sure changes are visible - this may be as simple as after a change is made requery the data and redisplay it, it is then up to the manager to check nothing was amended that conflicts with his update. If you really require only one update / user then web services are not the technology to choose and you may be better of going with a windows forms / transaction based application instead.

If you are connecting to SQLServer then use a SQLConnection rather than a OleDbConnection. The connection string for a windows authenticated connection has the form of "Data Source=;Initial Catalog=;Integrated Security=true" if you are using SQL authentication then it would be "Data Source=;Initial Catalog=;uid=;pwd=

Quick search on google brought up http://www.thecodeproject.com/dll/hookimport.asp but it's all in C / C++. If you are going to implement something like this you run a serious risk of interfering with other running applications unless you are very careful. Personally I would stay well clear of any application that did this unless there was an excellent reason for why it did so. I'm assuming this is in relation to the thread http://www.xtremedotnettalk.com/showthread.php?t=87759 and I must ask what is so important that a screen capture shouldn't be taken?

I would nearly always (except for the most trivial applications) use custom business objects in a middle layer. I would normally structure any decent sized application to contain: Data Access Layer - this handle the DB specifics, calls the stored procs, may implement some generic DB routines and should abstract out the choice of database being used. This layer will be dealing with DataSets, DataReaders etc. Business Layer - this layer will implement the core business logic, the objects will be populated from calls into the data access layer and ultimately all updates will also go through the DAL. Any front end (web, windows or even web services) will comunicate with the business layer and take advantage of the functionalilty offered there.