|
There has to be an ISA relationship between the classes before casting works.
i.e. If int inherits string then the follwoing works:
string foo="123";
int i=(int)foo;
See the Int32 inheritance heirarchy:
System.Object
System.ValueType
System.Int32
|
|
|
|
|
I'll just add - you should use int.TryParse if you have any doubts about the conversion. This requires that you have a string, or that ToString gives you the representation you're hoping for.
Christian Graus - C++ MVP
'Why don't we jump on a fad that hasn't already been widely discredited ?' - Dilbert
|
|
|
|
|
Please can somebody give me a useful link od discription how to record and immediate show a stream from a webcam or from a camcorder. I have tried with windows media encoder but this way is too slow
thx
|
|
|
|
|
Firstly, wrong forum, this is for C# specific questions.
Unless you fork out big bucks for specialised hardware you're not going to be able to do this, trust me on this, I've tried, the smallest latency I managed was 2 seconds and someone who spent several years doing this kind of stuff was impressed with it.
I have no idea what I just said. But my intentions were sincere.
Poore Design
|
|
|
|
|
When I start my app, any relative paths ("subfolder\filename.exe") are referenced from the directory the exe is located in. After I select a file in the file open dialog though, the folder of the selected file is used instead. How can I reset the default starting path back to the folder where my app was launched from?
--
Rules of thumb should not be taken for the whole hand.
|
|
|
|
|
Well, you could use the GetCurrentDirectory[^] method to get the current directory just before you open the dialog, then call SetCurrentDirectory[^] afterward to reset it.
But, if your code is written properly, you should never have to worry about this. This means your code shoud be written to use fully qualified path names in all cases, and not rely, at all, on whatever the current directory is.
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
Would that be done by calling GetCurrentDirectory at app start and saving the value to combine for creating absolute paths at runtime, or is there a different static method provided in the framework that already does so?
--
Rules of thumb should not be taken for the whole hand.
|
|
|
|
|
YOu can get the path back to the directory that the .EXE was started from by using Application.StartupPath . If you have files in the same folder, or any subfolder, you can build your fully qualified names from that.
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
Hello,
Dave Kreskowiak wrote: YOu can get the path back to the directory that the .EXE was started from by using Application.StartupPath.
Is there a designtime support for that?
Means, all the other ways (apart from System.Inviroment.CurrentDirectory) brougt me an obscure path at design time.
I needed this for a costum designed property.
All the best,
Martin
|
|
|
|
|
The current directory doesn't, or more to the point, shouldn't, have any meaning at design time. All paths should be built upon well known Special Folder returns or designated application roots specified by some kind of application settings, and verified before use.
Martin# wrote: I needed this for a costum designed property
Curious - How so?
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
Hello Dave,
But if more then one person is working on an application it is often the case, that the pathes don't mach, and so you have to have a kind of hirarchy with the starting point exe-path.
I give you an example:
For this property, we made a property designer which has to have access to a database file.
During designtime the person is entering this property which shows a form with all the database informations. He than is able to modify or choose one element of the form, which is then copied (as a string) to the property and stored in the initializecomponent code.
Also the costumer is allowed to copy the application with all the xml, xsd, db, ..-Files wherever he whants.
Maybe we made some bad mistake, but I think we had no other solution for that.
But I very interested to your response.
All the best,
Martin
|
|
|
|
|
Martin# wrote: But if more then one person is working on an application it is often the case, that the pathes don't mach, and so you have to have a kind of hirarchy with the starting point exe-path.
I have no idea what you're talking about. It doesn't matter how many people are using the same application. The .EXE path is always returned by Application.StartupPath. CurrentDirectory is not reliable to return that path.
Martin# wrote: For this property, we made a property designer which has to have access to a database file.
During designtime the person is entering this property which shows a form with all the database informations. He than is able to modify or choose one element of the form, which is then copied (as a string) to the property and stored in the initializecomponent code.
OK. So what? The path is stored in the startup code, preferably as a fully qualified or relative path, such as "\subfolder\file.xml".
Martin# wrote: Also the costumer is allowed to copy the application with all the xml, xsd, db, ..-Files wherever he whants.
OK. So your application builds the absolute path from Application.StartupPath and the relative path stored somewhere:
Dim path As String = Path.Combine(Application.StartupPath, "\subfolder.file.xml")
This will hold true and work no matter what folder the customer copies the .EXE file and subfolders/files to.
THere is just about never a reason to depend on CurrentDirectory unless you're writing some kind of commandline utility.
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
Hello Dave,
First, thank you for your time again!
I think there was a lot of misunderstanding from my side regarding to your words (like: fully qualified), because of my poor english and/or my programing skills! I actually was thinking that you don't like any kind of combining pathes for finding the exe path. Thats why I made that kind of long(useless) explination try before.
But I think there is one very important point for me which was not answered correctly, or maybe it was a wrong explination from my side.
I wrote: Is there a designtime support for that?
Means, all the other ways (apart from System.Inviroment.CurrentDirectory) brougt me an obscure path at design time.
Dave Kreskowiak wrote:
OK. So your application builds the absolute path from Application.StartupPath and the relative path stored somewhere:
Dim path As String = Path.Combine(Application.StartupPath, "\subfolder.file.xml")
This will hold true and work no matter what folder the customer copies the .EXE file and subfolders/files to.
Ok. But I tested it for my designtime needs, and it is not working!
The problem is that most methods or properties returning pathes like: "C:\Programe\Microsoft....\VS2003\Common7\IDE", instead of: "C:\MyFolder\...".
"System.Enviroment.CurrentDirectory" is the only property I found which works during run- and designtime in the same way.
Dave Kreskowiak wrote: THere is just about never a reason to depend on CurrentDirectory unless you're writing some kind of commandline utility.
Please let me know if this is still your last word, after my try to explain my problem a little better.
So, again thanks for your time and patience!
All the best,
Martin
|
|
|
|
|
Hello,
If you whant to have the path to the exe file, you should use:
System.Environment.CurrentDirectory
All the best,
Martin
|
|
|
|
|
That doesn't necessarily return the directory the .EXE is in. If the .EXE file is double-clicked, it will most likely be the corret folder, but if it was launched from a shortcut, the shortcut can specify a different directory than the one the .EXE is in.
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
Do you mean, we should care about the shurtcut directory?
Never needed that.
Or do you think, that then the shurtcut directory is shown?
Don't think so.
All the best,
Martin
|
|
|
|
|
Where I work, sadly, it's common to have a different path in the Working Directory, or Start In folder on XP shortcuts, than the path to the .EXE. The CMD equivilent of launching that shortcut goes something like this:
C:\> CD workingDirectoryPath
workingDirectoryPath> <pathToExe>\Executable.exe
The current directory, as returned in your code is workingDirectoryPath, not pathToExe.
Dave Kreskowiak
Microsoft MVP - Visual Basic
|
|
|
|
|
Hello Dave,
Thank you for the info!
I didn't even know that this is possible.
All the best,
Martin
|
|
|
|
|
Doesn't the OpenFileDialog.RestoreDirectory property do the trick?
Marc
Thyme In The CountryPeople are just notoriously impossible. --DavidCrow There's NO excuse for not commenting your code. -- John Simmons / outlaw programmer People who say that they will refactor their code later to make it "good" don't understand refactoring, nor the art and craft of programming. -- Josh Smith
|
|
|
|
|
hi every one ,
I'm working in C# 2.0 windws application and I wanted to know how can me make this happen u knnow. like forexample there is a login form and the user enters teh user name and password and then presses the enter key and it acts the same way as the button click event does, hope u got my point
thanks in advance
Rocky
|
|
|
|
|
Set the AcceptButton property on the form to the button that you want pressing. If you have a Cancel button, you can trigger that with the Cancel property.
the last thing I want to see is some pasty-faced geek with skin so pale that it's almost translucent trying to bump parts with a partner - John Simmons / outlaw programmer
Deja View - the feeling that you've seen this post before.
|
|
|
|
|
Hello,
Don't know if I understand you write.
But I think in this case, in the TextBox for the password or in both Textboxes (name and password) there is the KeyDown or KeyUp event watched.
like this example with two textboxes and one button:
this.button.Click += new System.EventHandler(this.button_Click);
this.tbName.KeyDown += new System.Windows.Forms.KeyEventHandler(this.textBox_KeyDown);
this.tbPassword.KeyDown += new System.Windows.Forms.KeyEventHandler(this.textBox_KeyDown);
private void Validating()
{
}
private void button3_Click(object sender, System.EventArgs e)
{
Validating();
}
private void textBox_KeyDown(object sender, System.Windows.Forms.KeyEventArgs e)
{
if(e.KeyCode == System.Windows.Forms.Keys.Enter)
{
Validating();
}
}
Hope I got you write!
All the best,
Martin
|
|
|
|
|
Whoa! Overkill!
myForm.AcceptButton = buttonOk;
That's all that's needed. Then pressing enter will process any code that is in your buttonOk.Click eventhandler method.
|
|
|
|
|
OK,
Never worked with this.
But if the focus is on the textbox, does the Form react also?
Or do you have to set KeyPreview to true additionaly?
All the best,
Martin
|
|
|
|
|
No, the focus can be anywhere on the form
|
|
|
|