|
Soumya92 wrote: VS gives me an error, saying that there is no constructor in A that can be called without any arguments.
Let's add that constructor then, and override the B sub;
Public Class D
Inherits A
Public Sub New(ByVal X As Integer)
MyBase.New(X)
End Sub
Public Overloads Overrides Sub B()
A = A + 2
End Sub
End Class
I are Troll 
|
|
|
|
|
If class D inherits From Class A and Class A has no paramterless constructor, then you have to have a constructor with at least the same signature as the original constructor and call MyBase.New(X). Your class D can have more parameters but one has to be an integer, which must be passed to the original constructor. If you think about it, it makes sense as you need to create an instance of both classes to create an instance of Class D.
|
|
|
|
|
The whole idea was to _not_ declare the constructor again. I agree that it makes sense to construct the base class object first, but I want the base class constructor to be used if I do not specify one in the derived class.
~ Soumya92
|
|
|
|
|
Soumya92 wrote: The whole idea was to _not_ declare the constructor again.
Sorry[^] 
I are Troll
|
|
|
|
|
In other words, you want to be able to create a new "D" using the constructor defined in "A"?
Short answer... You can't. Constructors don't inherit in .NET... You have to explicitly call them in a constructor in "D".
Public Sub New(ByVal X as Integer)
MyBase.New(X)
End Sub
If you have a lot of these subclasses, then you might want to move the initialization code out of the constructor and into an Initialize(X) sub that you could call after instantiating it. Easy enough to set a boolean flag so it can only be called once.
|
|
|
|
|
OK. Thanks a lot for your quick replies. We'll call the question resolved, then?
~ Soumya92
|
|
|
|
|
Yep, sorry it's not the answer you wanted.
|
|
|
|
|
I'm trying to patch/inject/hook (or whatever method is the best) a .net assembly exe. My objective is to extend the CollectionChanged event of all ListView classes in order to write the ListView content to a file.
The program uses a classe that extends from ListView to show some data. What I would like to do is use this data in another program I'm writing. I have already tried to use some OCR tricks but they are slow and sometimes does not produce the intended result.
I've tried to use reflector to find some info on the assembly but it is obfuscatored and I'm not very skilled reading il code : )
Is this even possible to archive?
What should I be looking for?
Any help would be much appreciated. (a working example would be great!)
Thanks in advance.
|
|
|
|
|
Maybe I posted this in the wrong section?
If so can someone please move it to the right section?
Thanks.
|
|
|
|
|
Hi all,
Do you noticed a difference about dll delay-load for assembly? We know that assembly is delay-loaded by default, and it is configurable for VC.
But there is a difference on when will it loaded...
in VC, the dll will be loaded only when code reached exactly the line that need another dll.
in .Net, it will load once it get into the method that calls another dll's code.
ex:
Dll1.dll
class Class1
{
void Fun()
{
int dummy = 0;
Dll2.Class1.Fun();
}
}
Dll2.dll
class Class1
{
void Fun(){}
}
For VC, it load Dll2 when code reached "Dll2.Class1.Fun();"
For .Net, it load Dll2 when code reached "int dummy = 0;"
any one can tell me why there is such a difference? thanks in advance.
do it.
|
|
|
|
|
You are quite allright.
why is it so?
In C you just blindly on the address and hope it works.
In .NET the JIT (Just In Time compiler) will compile the method on first call (i.e. transform it from MSIL to machine language), doing so it will make sure all calls are valid, hence it needs to check that all method call are reachable and with the right signature, i.e. it needs to load the DLL and check a few things such as: the dll exist, the version is right, the target methods exist, with the right signature, etc...
Otherwise the method will be deemed invalid and an exception will be thrown
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station....
_________________________________________________________
My programs never have bugs, they just develop random features.
|
|
|
|
|
I'm playing around with a System.Diagnostics.Process with its IO streams redirected.
Writing to input is working, and I'm able to do non-blocking reads from output by accessing the .BaseStream, but when I try that with the error stream it seems to block no matter what I try.
Has anyone else seen this? Have any ideas about how to accomplish non-blocking reads? Is there a setting I'm not seeing? Should I just not bother with the error stream?
(I don't simply want to do blocking reads on a different thread; I'd likely have to Abort the thread.  )
modified on Wednesday, March 31, 2010 2:22 PM
|
|
|
|
|
Hi PIEBALD,
I typically use two extra (background) threads to read the output and the error streams; it works fine for me on all NT-like versions (there always were problems on Win98/Me). The alternative would be to use the OutputDataReceived and ErrorDataReceived events (available since .NET 2.0), which get handled on a ThreadPool thread.
FWIW: one should not abort a thread; it is troublesome as the outcome is unpredictable.
|
|
|
|
|
Luc Pattyn wrote: one should not abort a thread
Which is part of why I don't want to use one for this; I don't expect any data coming from the error stream anyway.
Personally I have nothing against aborting a thread in such a case.
Luc Pattyn wrote: OutputDataReceived and ErrorDataReceived
But "the ErrorDataReceived event signals each time the process writes a line to the redirected StandardError stream" and I don't want to wait for complete lines, there may not be any newlines in the output -- I want non-blocking IO; if there's no data, just tell me there's no data!
And I expect it's executing on a thread which would have to be aborted in the background, so nothing is gained.
But the real mystery is why the two streams appear to behave differently.
|
|
|
|
|
If you don't like the way the events operate, you'll have to use your own threads and perform some kind of Read() calls. As I said, that is what I do.
BTW: I'm not sure I believe the documentation when it says the events fire on every output/error line, there probably is some buffering going on in the child process, hiding the individual WriteLine operations. I guess it only shows if sufficient data is available (some threshold exceeded) or maybe some data + some timeout.
PIEBALDconsult wrote: But the real mystery is why the two streams appear to behave differently.
I don't remember that. Do they do that consistently? which app(s)?
|
|
|
|
|
Luc Pattyn wrote: Do they do that consistently?
They seem to. Output will return 0 when there's no data, but error will block indefinitely. It could, of course, be due to output having data some times and error never does. I'd have to write a little utility that will write to error to test that out.
Luc Pattyn wrote: which app(s)?
So far, I've been testing with a utility of mine, I'll try it with FTP or something.
WTF!  FTP and telnet don't seem to be prompting when run in a Process!
NSLOOKUP prompts, but I still hang when trying to read the error stream.
modified on Tuesday, March 30, 2010 7:37 PM
|
|
|
|
|
I wrote a little console app that writes its output to error rather than output and it worked fine.
|
|
|
|
|
I just experimented a bit with process stream redirections and created this article[^]. It all works as I expected.
|
|
|
|
|
But what if the slave uses Write rather than WriteLine?
I suppose I could download your code and try that myself...
|
|
|
|
|
the way standard output & error work in .NET is optimized for line-oriented processing; I am guessing the slave process emits output/error data through some buffers, these get transferred occasionally (independent of newlines), the master gets hold of those buffers and searches for line terminators; for each one found it triggers a DataReceived event. AFAIK the underlying i.e. Win32 mechanism is not line-oriented. You not using NewLine means DataReceived events are useless for you, so you need either threads or async operations and collect and parse incoming data yourself.
the one point I have been making is output and error are handled basically the same (although I have a suspicion there may be more buffering at the sender side for stdout than there is for stderr).
|
|
|
|
|
Luc Pattyn wrote: DataReceived events are useless for you
Right. I just tested it and saw what I expected.
Luc Pattyn wrote: underlying i.e. Win32 mechanism is not line-oriented
Right, and using the .BaseStream almost works -- e.g. it works for Output, but not for Error. I wonder whether or not I can get lower...
The only thing I can think of that would cause the difference in behaviour is different backing stores, but why would the two streams have different backing stores? 
P.S. I added commands:
"o" -- Out.Write
"e" -- Error.Write
"a" -- I made autowait an int; "a" decrements it, "A" increments it
|
|
|
|
|
|
I was just poking around in the non-public fields...
Out is a System.IO.__ConsoleStream
Error is a System.IO.NullStream 
|
|
|
|
|
What is the difference between "Excel 2007 Add-in" project and "Excel 2007 Workbook" project ?
|
|
|
|
|
The Add-in allows you to write a plugin for Excel, and it will be loaded when Excel starts. The first is an application-level addin, the second a document-level addin.
Start here[^] 
I are Troll 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
