|
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 
|
|
|
|
|
|
Hi,
I have a database (access) that contains a table GALLERY.
Now i need while uploading a file to insert the path in this way to the db
"~/photo/XXX.JPG"
What i get right now is only the file's name.
This is what i used for saving the path
FileUpload1.SaveAs(Server.MapPath("~/photo/" + FileUpload1.FileName));
I've tried it with and without the Server.MapPath.
The resault without the server.mappath was "The SaveAs method is configured to require a rooted path..bla bla bla"
With the Server.MapPath it works but not the way i need it. as i said it inserts only the file's name to the DB.
Can anyone please help me with that.
Thank you,
Basil.
|
|
|
|
|
Do not post to multiple forum 
I know the language. I've read a book. - _Madmatt
|
|
|
|
|
What database are you using. If your database generate the problem on saving the file path. You can Encrypt the path and Then save to it.
If you can think then I Can.
|
|
|
|
|
im using an ACCESS DB, what do you mean by encrypting the path
|
|
|
|
|
If you are using Access DB then replace the \ to \\ and save it.
the second method is to save in database is encrypt the path.
If you can think then I Can.
|
|
|
|
|
thanks for your answer, please tell me what do you mean by encrypting the path, you mean to encrypt the path string before inserting to the DB, how would i do that ?
|
|
|
|
|
If your Path Name have a Special Character that database is not support. Then you can use to convert this path to a another string by using diffrent encryption method.
If you can think then I Can.
|
|
|
|
|
i need you to tell me HOW to encrypt it
|
|
|
|
|
|
My c++ dll takes as input char*.
.
bool testdata(char* data, int dataLen)
From Vb I am doing the following
Declare Function testdata Lib "\abcDLL.dll" (ByRef data As Byte(), ByVal dataLen As Integer) As Boolean
Structure Test
Public header As UInt32
Public lst As UInt32
End Structure
'
Private Function StructToByte(ByVal Struct As Object) As Byte()
Dim iStructSize As Integer = Marshal.SizeOf(Struct)
'Dim iStructSize As Integer = Len(Struct)
Dim buffer As IntPtr = Marshal.AllocHGlobal(iStructSize)
Marshal.StructureToPtr(Struct, buffer, False)
Dim btData(iStructSize - 1) As Byte
Marshal.Copy(buffer, btData, 0, iStructSize)
Marshal.FreeHGlobal(buffer)
Return btData
End Function
While calling the above function
Dim tFrom As Test
tFrom.header = 200
tFrom.lst = 200
Dim ByteArray2() As Byte
ByteArray2 = StructToByte(tFrom)
testdata (ByteArray2, 8)
PROBLEM:
The problem is that when in the dll I type cast the ata into a struc containing only 2 integer, I get incorrect values.
I am strugglign with this for the last 2 days, can anyone plese help me out
|
|
|
|
|
This may be unsafe, but you can directly pass a VB String to C++ dll that take const char * & or something like that depending on whether you pass by value or reference. For that matter you can pass VARIANT or _variant_t's as well using COM.
When you want to modify the string from VBA, then you need to use a bytearray. Otherwise, it is unnecessary.
|
|
|
|
|
You should post this question to the Visual Basic forum, as you are more likely to get an answer there.
txtspeak is the realm of 9 year old children, not developers. Christian Graus
|
|
|
|
|
I have a class, call it Inventory, it does some basic database tasks using a BackgroundWorker like SaveChanges(), LoadFirstItem() etc. In my RunWorkerCompleted method PropertyChanged events are fired to notify the UI to update itself.
This works swimmingly in my WinForms app and the BackGroundWorker is clearly doing it's thing successfully, but I'm having trouble writing [TestMethod()]'s for the class in a test project. In a test project, it seems like after calling RunWorkerAsync the DoWork method doesn't get called, and as a result neither does RunWorkerCompleted, and my tests always fail.
Breakpoints in DoWork or RunWorkerCompleted are not hit. I assumed this was because my test method was not waiting for the background thread to finish so I've tried sleeping the main thread to see if the BackgroundWorker can catch up, I've tried the Application.DoEvents() thing, but I'm a bit of a rookie in the threading department... and the authoring of Unit Tests department for that matter! uh oh
Any pointers on how to please my BackgroundWorker in a [TestMethod()]?
|
|
|
|
|
Hi Jack,
Not sure, but I would guess your test framework is being run from some thread other than the main thread.
BackgroundWorker (and other threads) are not allowed to touch GUI Controls directly, you know that. Some of their events (ReportProgress and RunWorkCompleted) take care of the thread barrier automatically, but only so when the BackgroundWorker got created by the main thread. Weird things could happen when an arbitrary thread creates a BGW whose event handlers in turn try to modify the GUI.
To make sure whether your DoWork method gets called or not, I suggest you simply insert a MessageBox.Show(), that one doesn't care about thread boundaries at all. An alternative diagnostic tool is:
Console.WriteLine("Method XYZ running on thread "+Thread.CurrentThread.ManagedThreadId.ToString("X2"));
which allows you to visualize the thread on which the caller is running.
|
|
|
|
|
First of all, sorry for the tardy reply.
With your suggestion I was able to confirm DoWork was running, the Test Framework was on thread 12, DoWork was on 14.
Now I'm wondering, if the BackGroundWorker only knows how to notify the "main" thread, and the Test Framework is not on the main thread, doesn't that mean I'm sort of stuck with testing this BackGroundWorker business?
Since I know the DoWork methods are running I suppose I could run a separate set of tests to confirm their results, but ick
Or, maybe I could ditch the BackGroundWorker and code the necessary threading behaviour myself? Do you think I could work around my issue in this way?
|
|
|
|
|
There is no need to ditch the BackgroundWorker at all; when a BGW is created by the main thread, one of its major advantages is its ReportProgress and RunWorkCompleted events run on the main thread too; when created elsewhere, you loose that advantage, but that is what regular threads do all the time.
So you would have to explicitly call Control.InvokeRequired and Control.Invoke to get the results towards your GUI, as if your BGW where just another thread. See e.g. here[^] for details, in case you need a refresh.
There might be an alternative, fiddling with SynchronizationContexts, but I'm not familiar with that.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
