|
AFAIK, there isn't a unique hardware number as such. Microsoft use a psuedo one which is built from things like hard disc serial numbers and such things and that's why if you upgrade your computer with new discs etc. you are sometimes asked to reactivate Windows. It looks like a new machine.
You'll need to be prepared to take similiar steps if your customers do such things. Probably getting the serial number of the hard disc is close enough, think there's plenty on how to do that such as:
http://www.eggheadcafe.com/articles/20021019.asp[^]
Regards,
Rob Philpott.
|
|
|
|
|
Then probably no one will use your software.
Make your software free, perhaps as a beta, and see how many people actually want to use it before trying to do anything like that.
|
|
|
|
|
I totally agree with you - nowadays you can get pretty much any software for free and unless you are creating enterprise level software, to sell to people who want everything to work on an iPad as well as their PC, your best bet is to make the software free and gain revenue from advertising on your download site.
Continuous effort - not strength or intelligence - is the key to unlocking our potential.(Winston Churchill)
|
|
|
|
|
A previous employer of mine used the "Armadillo" system for such a thing (see http://www.siliconrealms.com/armadillo.php[^]). You can configure it such that it comes with a trial period of say 30 days - uninstalling an re-installing would not create another trial period. But I am not sure if it can be used now with .NET applications.
|
|
|
|
|
You can use the volume serial number, which is unique for your hard disk, i.e. every machine will have a different one.
|
|
|
|
|
Its been discussed everywhere that a class cannot inherit from multiple classes but can implement multiple interfaces. My question is how many interfaces can be implemented on a single class?
Shouldn't a class have a single responsibility? In case of multiple interface implementation, doesn't it allow classes to have multiple responsibilities?  What exactly is the idea behind classes going for multiple interfaces and implementing them all on a class? What number of interfaces is good or is bad? (Though "number" may not have a meaning here, I mean to ask what goes into deciding that a class should/shouldn't implement an interface) 
Any help in this area from anybody shall be of great help. 
|
|
|
|
|
There is no limit to how many interfaces a class can implement.
It clearly depends on your requirement.
The class gets complex with each additional interface implemented.
Allowing multiple interfaces to class gives us some benefit of being robust and scalable.
Practically, a typical class implements one or two interfaces. but, again it depends on what you want to achieve.
// ♫ 99 little bugs in the code,
// 99 bugs in the code
// We fix a bug, compile it again
// 101 little bugs in the code ♫
|
|
|
|
|
|
Ravi Sant wrote: There is no limit to how many interfaces a class can implement.
I seriously doubt that.
Everything on a computer has a limit.
|
|
|
|
|
yes practically everything has limit, but if limit is very huge, compare to practical requirements
// ♫ 99 little bugs in the code,
// 99 bugs in the code
// We fix a bug, compile it again
// 101 little bugs in the code ♫
|
|
|
|
|
|
This is a good question. I guess the answer is that the 'single responsibility' principle is at a somewhat higher level than interfaces, many of which specify a behaviour and not a 'responsibility' as such. For example, would you consider INotifyPropertyChanged or IEnumerable<T> to be 'responsibilities'? I wouldn't, I'd say they label the class as having particular behaviours but tell you nothing about what the class actually does.
Another case where it can make sense is where you have a class (or an aggregate class with references to several others) whose responsibility is as a data store. This could be auto-generated from an entity management framework or just in-memory classes. You could specify several interfaces on it for different ways of looking at the data – typically, at least, some of those classes will be enumerable, but you could also create custom interfaces for domain-specific things that you want to be able to do with data. For example let's say you're writing a graphics library, and you want graphs to draw series, you might have a ISeriesDataProvider, and it would make sense to make any of your data storage classes that wrapped a list of numbers implement that. The responsibility of that class is not to provide numbers for a graph – it's still to store the data – but it is a useful behaviour.
So your primary thinking is correct: you should only inherit from one 'responsibility provider', whether that be a class or an interface. (Sometimes you inherit from none and write the responsibility into this class, of course.) But you can implement any number of 'behaviour decoration' interfaces.
Defining the difference between 'responsibility provider' and 'behaviour decorator' is quite tricky but a good clue is that behaviour decorators usually have only a small number of methods or properties, and what those methods/properties do (and are called) is generic, not domain-specific. For example IEnumerable has one method, INotifyPropertyChanged one event, and my hypothetical ISeriesDataProvider has one property (the data), and the names of those single entities tell you nothing about the rest of the class. IEnumerator has three, which are quite general; I'd consider it a borderline case based on that, though because we know what it is, it is clearly a responsibility provider (an enumerator is there only to enumerate). IList has several and most of them have list-related names (add, remove, etc), so it is clearly a responsibility provider, and you shouldn't generally implement it unless your class is primarily a list.
Note that I just made up the terms 'responsibility provider' and 'behaviour decorator' in the process of writing this post and they may have proper names which I'm not aware of.
|
|
|
|
|
@BobJanova
Thank you very much for replying to my question. 
The main problem I was facing, as you rightly pointed out, was in distinguishing the meaning between responsibility and behaviour and hence couldn't tell if I can implement interfaces IA to IZ on a class without affecting its responsibilites. Through your terms "responsibility provider" and "behaviour decorator" I now understand interface implementation clearly. Thank you very much for the help. 
|
|
|
|
|
goodpeapul wrote: Shouldn't a class have a single responsibility?
Generally, an interface represents a lightweight "behavior" (that is independent of other behaviors) while a class represents a heaver weight "provider of services" (with potentially predefined methods operations). So it's perfectly acceptable for a class to implement several interfaces while still having a single overall responsibility.
/ravi
|
|
|
|
|
Thank you very much Ravi Bhavnani. The information you have provided here was useful to me.
|
|
|
|
|
goodpeapul wrote: My question is how many interfaces can be implemented on a single class?
In my humble opinion asking "how many" is not quite the right focus on the broad issue of why and how to use Interfaces.
Clearly Interfaces can have multiple uses:
1. to enforce an implementation contract on implementers of an Interface. That "contract" forcing you at compile-time to deal with failure to 'meet the terms of the contract.'
2. to encapsulate "shared behavior" used consistently across implementers of the Interface.
3. via casting instances of Interface implementers to the Interface: to expose a limited subset of functionality, or content, of the instance to other Objects.
4. via discriminate use of implicit and explicit Interfaces to obtain the advantages of all of the above while avoiding semantic confusion, or overlap.
imho the idea of "single responsibility" is as applicable to a set of behaviors (methods, functions), as it is to classes.
Interfaces are one tool to help achieve that.
It may be of interest to you to read Erich Gamma's comments on interfaces here in this 2005 interview:[^]: scroll down to the section titled "Program to an interface, not an implementation."
From a humble student of Interfaces and their strategic uses.
best, Bill
"I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone." Bjarne Stroustrop circa 1990
|
|
|
|
|
I am working on a C# WPF application that makes use of the OpenNET CF Desktop Communication library. My program waits for an Active Sync connection and uploads a small EXE. The EXE gets the device manufacturer and model and writes them to text files. I then copy those text files back to the desktop PC to grab that data. I wish I knew how to run those over a socket, but that's for another day. I would like to create a separate thread so that I don't block the main UI. This separate thread must NOT complete until it detects that the EXE I uploaded has finished and created the text files. I would like to have it essentially sleep for 1 second and check, and if it gets to more than 5 seconds alert the user that an error occurred. The problem I'm having is figuring out how to sleep the thread. I'm using a while loop that runs so long as those text files are not present. Once I go into a while loop, all variables are local. As a result, I cannot access the DispatcherOperator so I can invoke the sleep in the form of a 'Wait'. In place of it I am currently sleeping the main thread, but this blocks the UI. How can I achieve the effect of this separate thread waiting for the text files to be output by the EXE I uploaded to the mobile computer, but also not blocking the main UI?
<pre lang="c#">
private void MonitorOEMInfoProcess()
{
System.Threading.Thread MonitorThread = new System.Threading.Thread(
new System.Threading.ThreadStart(
delegate()
{
System.Windows.Threading.DispatcherOperation dispatcherOp = Dispatcher.BeginInvoke(
System.Windows.Threading.DispatcherPriority.Normal,
new Action(
delegate()
{
while (!m_rapi.DeviceFileExists(@"\Application\OEMName.txt") || !m_rapi.DeviceFileExists(@"\Application\OEMVersion.txt"))
{
System.Threading.Thread.Sleep(1000);
}
}
));
dispatcherOp.Completed += new EventHandler(dispatcherOp_Completed);
}
));
MonitorThread.Start();
}
|
|
|
|
|
I may be totally wrong at this but it looks like you're starting a background thread via
new Thread(ThreadStartDelegage). That's fine so far.
But the background thread itself wraps its work in a Dispatcher.Begininvoke() so that it actually runs, and Sleep()s, in Dispatcher's thread. This can or can not be the main thread, depending on how you created Dispatcher.
Ciao,
luker
|
|
|
|
|
I'm not sure which method to use (dispatcher or not). All I do know is that I need the process to run asynchronously from the main thread and to not block the UI while it checks for the presence of those files on the mobile computer. I have another glitch with it: the files may already be present on the device from a previous run, and so just checking for the presence of those files is a bad idea. What I really need to check for is if the EXE that I kick off on the mobile computer is finished, and that the text files that it writes to are available. There are some instances where I try to copy the file back to the desktop PC and the RAPI service can't copy it because the process running on the mobile computer still 'owns' it. Since there isn't a way for me to monitor that process directly, I've decided that sleeping for 5 seconds is enough. I want that sleep, however, to be asynchronous and not blocking the main UI. When a device connects and ActiveSync brings up its windows, I want to minimize them. If those windows are over top of my application and I minimize them, the sleep is currently blocking the UI and so the UI window shows remnants of those ActiveSync windows until the sleep finishes and the UI updates again.
Regards,
Scott
|
|
|
|
|
You have BobJanova's answer that does the file lookup in a separate thread without blocking the UI.
But regarding the other problems you mention, I suggest you should think again if it's worth developing the file handling way. You already mentioned that in the long run you would rather choose a socket-based communication. Maybe now is the time to get that version going.
Ciao,
luker
|
|
|
|
|
private void MonitorOEMInfoProcess()
{
System.Threading.Thread MonitorThread = new System.Threading.Thread(
new System.Threading.ThreadStart(
delegate()
{
while (!m_rapi.DeviceFileExists(@"\Application\OEMName.txt") || !m_rapi.DeviceFileExists(@"\Application\OEMVersion.txt"))
{
System.Threading.Thread.Sleep(1000);
}
}));
MonitorThread.Start();
}
Dispatcher is for synchronising things back to the main thread, you don't need it here.
|
|
|
|
|
The first code works, however I need to be able to read contents of multiple files from a particular directory.
Start simple and build from there I figure. Doing something wrong somewhere, as the 2nd code only brings up the dos window without any data.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;
namespace readtest
{
class Program
{
static void Main(string[] args)
{
StreamReader sr = new StreamReader("C:\\Users\\Random.txt");
string str = sr.ReadLine();
string[] words = str.Split('|');
foreach (string word in words)
{
Console.WriteLine(word);
} Console.ReadKey();
}
}
}
This is the one I need to have working. I must be structuring something wrong. I've tried different ways, but no luck.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;
namespace ConsoleApplication2
{
class Program
{
static void Main(string[] args)
{
string[] files = Directory.GetFiles("C:\\Users", ".txt");
foreach (string file in files)
{
StreamReader sr = new StreamReader(file);
string str = sr.ReadLine();
{
Console.WriteLine(file);
}
} Console.ReadKey();
}
}
}
|
|
|
|
|
Member 8363084 wrote: string[] files = Directory.GetFiles("C:\\Users", ".txt");
you have to use * here as
string[] files = Directory.GetFiles("C:\\Users\\", "*.txt");
regards
|
|
|
|
|
try
string[] files = Directory.GetFiles("C:\\Users\\", "*.txt");
Although it may read a bit better with an @ sign
string[] files = Directory.GetFiles(@"C:\Users\", "*.txt");
"You get that on the big jobs."
|
|
|
|
|
To cut to the chase, our current connection string is:
Provider=Microsoft.ACE.OLEDB.12.0;Data Source={0};Extended Properties='Excel 12.0 Xml;HDR=YES;'
We really do not have the option of pushing a TypeGuessRows registry change to all users in order to force Excel to scan the whole column.
Can TypeGuessRows be given as an extended property to the ACE Provider?
Note: I know this isn't necessarily a C# specific question, but I'm writing in C# using an OleDbCommand, using the connectionString above.
"I need build Skynet. Plz send code"
|
|
|
|
|
There's no way to force TypeGuessRows in the connection string to a different value. I think your only option is to append "IMEX=1" to the connection string, which forces Excel to read all column data as text only. You'll then have to parse out out values from the strings returned.
|
|
|
|
|
btw, MS advised that the following should be correct:
Provider=Microsoft.ACE.OLEDB.12.0;Data Source={0};Extended Properties='Excel 12.0 Xml;HDR=YES;Imex=1;ImportMixedTypes=Text;TypeGuessRows=0;
"I need build Skynet. Plz send code"
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
