|
maybe instead of installer feature make it an application setting..
using registry for example:
RegistryKey key = Registry.LocalMachine.OpenSubKey(@"Software\Microsoft\Windows\CurrentVersion\Run", true);
key.SetValue("%app_name%", Application.ExecutablePath);
key.Close();
life is study!!!
|
|
|
|
|
|
In what sense is it not solved yet? You are going to have to give us all a clue!
CCC solved so far: 2 (including a Hard One!)
37!?!! - Randall, Clerks
|
|
|
|
|
My setup should create a copy of "exe" here..
"Users\Guest\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\startup\My.exe"
so when users logon to his system then it will run automatically...
If there are anyother way to do that please let me know.
|
|
|
|
|
in the directory you pointed should be only a shortcut..
and it's done in a way keefb described
life is study!!!
|
|
|
|
|
Yes worked!!
Thanks guys...
|
|
|
|
|
Hi,
I was writing a validation function. Which is as follows
private void IsFolderValid1()
{
return false;
}
and somebody suggested me to write it in following way.
private void IsFolderValid1()
{
Get
{
return false;
}
}
Can u please explain me the reason. Whether it is right or wrong ?
Thanks
|
|
|
|
|
Your first version is right. Getters and Setters should be used for properties.
|
|
|
|
|
Hi,
none of that is correct, for several reasons:
1. if a property or method returns "false" its type should be boolean, not void.
2. property and method names normally shouldn't contain digits
3. method names normally contain a verb, and property names may or may not (preferably not, although IsValid would be acceptable)
4. private members use pascalCase, public ones CamelCase.
5. properties should always be public (protected could be OK, private is a bit strange).
6. properties don't take parentheses.
So choose one of these:
public boolean IsFolderValid() { ... return false;}
public boolean FolderValid {
get { ... return false; }
}
|
|
|
|
|
Hi there
I am building some database layer code and trying to be as database independent as possible.
One peeve is datetimes.
Does it make sense to avoid the use of the datetime objects provided by the database provider altogether and use a double field? Then use persist the dates to the double field using the DateTime.ToOADate method?
It seems to me then that I could easily do date comparisons such as "retrieve rows where date > <date>" where the <date> is converted to OA?
|
|
|
|
|
Why not just store the dates as ISO-8801 format?
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
peh. store dates as strings? what's wrong with the existing date and datetime types, they have sufficient support.
IMO strings should be avoided for anything that isn't really a string, i.e. numbers, dates, ..., with a possible exception for small binary data encoded with say base64 (when BLOB isn't available or too expensive).
and then of course one should use SQLparameters to provide data, not string literals, when querying with e.g. a WHERE clause.
|
|
|
|
|
Luc Pattyn wrote: what's wrong with the existing date and datetime types,
For one, MS SQL Server only supports a subset of DateTime values, so your business layer needs to work around this before you store them in the db. Note, I'm not advocating store timestamps as strings.
/ravi
|
|
|
|
|
Except that bubba there wanted to make it db agnostic, and I've worked with a couple of databases in the past that have crap date and time support (hello Ingres, yes I'm talking about you, you malformed piece of relational dataloss crapturd).
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
we could agree on Ingres not being a database then, hence no need to dumb down the whole world and turn agnostic into stupid. Next someone will find a "database" that can't handle real numbers; or strings of more than 6 characters; or Unicode...
When he asks "Does it make sense to avoid the use of the datetime objects..." my answer is NO.
|
|
|
|
|
Or one that doesn't have operator precedence?
|
|
|
|
|
Luc Pattyn wrote: When he asks "Does it make sense to avoid the use of the datetime objects..." my answer is NO.
I'd agree with that
Luc Pattyn wrote: agree on Ingres not being a database
and that.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
Pete O'Hanlon wrote: I'd agree with that and that.
I'm glad to see you're back to normal; I suggest you keep ignoring the toaster.
|
|
|
|
|
Luc Pattyn wrote: I suggest you keep ignoring the toaster.
I've kicked the hussy out. I only have eyes for the microwave now.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
Pete O'Hanlon wrote: I only have eyes for the microwave now
I must warn you, microwaves can harm the eyes. And Ray-Ban won't offer adequate protection.
|
|
|
|
|
Ryan Minor wrote: Does it make sense
No, it doesn't.
I use several different database systems and the only problem I've had with DateTimes is that they don't all agree on which range of dates to support. So unless you're storing historical (or far future) data, you probably won't have any trouble.
|
|
|
|
|
IMHO adding a non-exhaustive list of those DB systems would turn that into the perfect answer...
|
|
|
|
|
Ooookaaay... I'll get right on that.
|
|
|
|
|
One thing to bear in mind is whether this database will be used for anything else, e.g. accessed directly from reporting tools rather than through your application code. In this case, holding the dates as a double may cause problems for the person writing the reports.
Personally, I would consider making the data access layer pluggable, with a separate table gateway[^] for each RDBMS you are going to support. That way, if your database has good date type support you can use it, if not you can fall back on using doubles. Either way, the bulk of your code doesn't know and doesn't care. In fact, you might only need two gateways: one that supports date types and one that doesn't. Then you have a simple configuration switch to flick at deployment time to control how the application stores data.
(Actually, that link above isn't the most helpful in the world. Buy the book, it's very good.)
|
|
|
|
|
hi,
i have developed a windows service with c# and in my service a routine run at specific time to fetch data from sql server but i saw sometime i am getting error like below
A network-related or instance-specific error occurred while establishing a connection to SQL Server
can anyone tell why i am getting the above error some time. please help.
thanks in advance
tbhattacharjee
|
|
|
|