|
You can't convert this to catch a File Open. There is no hook for that. What, exactly, do you want to accomplish by hooking the File System?
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
I would like to intercept open calls by any applications that try to open files with the *.txt, for example. I would like to perform some routine before the application proceeds with the open.
|
|
|
|
|
You would have to write what is essentially a device driver. The driver would attach to the NTFS file system and report back with the details your looking for. You can't do it entirely in VB.NET. The .NET languages, except for C++, are too high-level for work like this. You could write your app that does the actual reporting in VB.NET, but the driver work is best done in C++.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Would you happen to have a sample of this in C++ or a site that I can go to for more info?
|
|
|
|
|
Nope, and I doubt you'll find many samples either. It requires very deep knowledge of the internals of NTFS and Windows to write one. People usually bill you for that kind of knowledge. But...
There is an example of such a technique in the FileMon utility at www.sysinternals.com. There is no source for it, you you'll see the .dll in the package. Under the Source nav menu on the left side of their page, you'll find a utility called FunDelete. There is source code in its .ZIP file that demonstrates some of the techniques you'll need to get one these drivers running.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Thanks. I will have a look.
|
|
|
|
|
Hi.
I’m trying to write and if then statement that checks to see if a string contains a certain value.
Here is how I thought it worked:
If TheString.IndexOfAny(“This Text”) then
I want the statement to return True if the string contains “This Text” anywhere within the string.
Can anybody tell me how this should be written?
Thanks
Brad
|
|
|
|
|
There is a function in Microsoft.VisualBasic called Instr that can, given two strings, give you the number of times that string2 occurs in string1.
Try using this function
<br />
Function ContainsStr(Str1 As String, Str2 as String) As Boolean<br />
Return (Microsoft.VisualBasic.Instr(Str1, Str2) > 0)<br />
End Function <br />
Hope This Helps
|
|
|
|
|
This looks like it will do the trick.
Thank you very much!
Brad
|
|
|
|
|
i think it will work like this .
if theString.IndexOfAny="This Text" then
ROLI
|
|
|
|
|
|
declare a boolean variable as say
Dim val As boolean
then after the statement,
If TheString.IndexOfAny(“This Text”) then
type
val="true"<br />
Endif
OR
return "true":|
u can then reference variable val elsewhere as the value returned
|
|
|
|
|
I am trying to play and increment tracks in a listbox control with the windows media player active x control (OCX).
The following line of code will play a selected item.
AxWindowsMediaPlayer1.URL = ListBox1.SelectedItem
I need to be able to start from a point in the listbox, for example the third
track, with out selecting it with the mouse, and then I need to play and increment through the tracks.
The following line gives me an error that the list box has no default property:
AXWindowsMediaPlayer1.URL = ListBox1(3)
Any sugestions?
Many thanks,
Glen Conaway
|
|
|
|
|
It's right, there is no default property like there was in VB6. You have to use something like this:
AXWindowsMediaPlayer1.URL = ListBox1.Items(3).Text
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Ok, Thanks,
But I still have a problem, I am getting the following error message:
An unhandled exception of type 'System.MissingMemberException' occurred in microsoft.visualbasic.dll
Additional information: Public member 'Text' on type 'String' not found.
Many thanks,
Glen Conaway
|
|
|
|
|
Glen Conaway wrote:
Additional information: Public member 'Text' on type 'String' not found.
The objects in ListBox.Items() are strings, so just try ListBox.Items(1), instead of ListBox.Items(1).Text.
Hope This Helps
|
|
|
|
|
Works great.
Many thanks,
Glen Conaway
|
|
|
|
|
Sorry for the late reply, but yes, drop the .Text. That's what I get for writing this stuff when I'm in a hurry to get out of work!
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
I am at the stage that I realized that alot of my exceptions are being handled poorly, and have now created a class that will handle the exceptions that are thrown at one point in the program rather than at the many that existed before. (based on the article on exception handling on this site)
BUT, now that I am going through I see alot of places that I am unsure whether it is a place that should be within a try/catch block or not.
Here is a simple example:
let's say that you are about to create an object that requires one or more params. If the params are not there you do not want the code to continue because obviously the later code requires the object. Now this seems to me at this point to enclose this within a try/catch block. Is that wrong, because this kind of thinking would result in ALOT of t/c blocks throughout the program, and I know that they can take their toll on your system.
I guess that it is things like this that I am want to make sure of because I don't want to have to make a bunch of changes a couple weeks down the road to changes that I need to make now.
Thanks for the help.
|
|
|
|
|
another question:
is there any harm in only catching the std exception if you are not going to deal with any other exceptions differently? That is the way that I am doing it now, but I want to make sure.
Thanks again
|
|
|
|
|
We use the thread exception handler to catch all "unanticipated" exceptions. Then in code elsewhere we only write exception handlers for expected errors that we specifically want to do something about (file not found, etc.). We also include a fair number of Try/Finally blocks to be sure we cleanup when an error occurs (close files, release handles, etc).
This scheme seems to work pretty well ... but I would certainly be open to other opinions and ideas
A person with one watch knows what time it is; a person with two watches is never quite sure ...
[remove "NFS-" from email (No Freaking Spam)]
|
|
|
|
|
===we only write exception handlers for expected errors that we specifically want to do something about (file not found, etc.).
what is the benefit of handling exceptions of that sort at that point? Because right now all mine are being thrown to the global e catcher Is there any disadvantages that I am missing out on that will come to haunt me later?
|
|
|
|
|
kowplunk wrote:
what is the benefit of handling exceptions of that sort at that point? Because right now all mine are being thrown to the global e catcher Is there any disadvantages that I am missing out on that will come to haunt me later?
Well, if the user attempts to open a file, it would be nice to catch the FileNotFoundException and the tell user to try again (or jump off a bridge ), or the SecurityException so we can tell the user he/she's got insufficient rights to open the file, or ...
It just depends on what the function does and what you want to do in the even of an exception. Production quality code is HEAVILY populated with exception handlers just because of the little things like trying to open a file that doesn't exist. You could encompass your app with one giant exception handler, but that would also mean that any error would effectively stop your app in its tracks and you would have to restart it.
RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome
|
|
|
|
|
Blaiser wrote:
We use the thread exception handler to catch all "unanticipated" exceptions
Does this mean that you have the whole program running within one big t/c block?
|
|
|
|
|
kowplunk wrote:
Does this mean that you have the whole program running within one big t/c block?
Not really, but it does have that effect. I think of it as a last stop safety net; any errors that occur on the thread which are not otherwised handled get caught here.
Back in VB6, any production app worth its salt would have an error handler in every event routine because if an error occurs here, the app just croaks after VB gives its default error message.
But in .NET you can set an exception handler for the thread, and only write handlers for the errors you can do something about. Like Dave said, if the file a user selects does not exist, or is the wrong format, or they don't have the privs, I'll catch these, provide a specific message, perhaps log the occurance and move on. But if some other kind of error occurs that I don't anticipate, like "Index out of bounds" or "Object is Nothing" (i.e. a defect) then the global handler will catch this, log it, inform the user and give control back to the UI.
Now, as I said, we employ a good number of Try/Finally blocks through-out to be sure we release resources properly (close files, etc.), whether an error occurs or not. But the global handler has worked pretty well for us.
One last point, I would not loose too much sleep over the performance impact of having t/c blocks in your code. IMHO, excepting certain constructs (like tight loops), the impact is generally negligible relative to human response time in using the GUI. $0.02
A person with one watch knows what time it is; a person with two watches is never quite sure ...
[remove "NFS-" from email (No Freaking Spam)]
|
|
|
|