|
CleaKO wrote: I just found a message from 2004 that said there is no option for opening a file
and adding text to the beginning. I want to validate whether that is still true
or not.
Yes, it's still true, until someone creates an entirely new file system that supports writing at either end of a file instead of just the end.
CleaKO wrote: What I want to do is add some data to the beginning of a file without reading
and writing the entire file.
Can't be done. The only way to prep for an operation like that would be to pad the beginning of the file to save room for writing from the beginning of the actual content of the file.
|
|
|
|
|
It was your reply that I found earlier, .
Thanks for confirming.
CleaKO
"Now, a man would have opened both gates, driven through and not bothered to close either gate." - Marc Clifton (The Lounge)
|
|
|
|
|
If you feel a need to do that, it should tell you huge text files are not the right approach.
If your data would reside in a series of files, with some particular order imposed (maybe alphabetically sorted file names), then you could insert at the beginning, at the end, and at each file switching point, simply by adding one more file with the appropriate characteristics (e.g. filename) that make it sit where it belongs.
|
|
|
|
|
Writing a file isn't an "insert operation". It's modifying what's there, or writing beyond it's limits if there's room.
--edit;
Just reread Luc's post
Bastard Programmer from Hell
|
|
|
|
|
My application is in VB.NET and environment is Window XP. We are using WebBrowser control to display data of Word doc files i.e. we are opening word files always inside the WebBrowser control and then modifying word file using bookmarks by VB code.Our VB code is perfectly working. We are doing following changes in window registry via VB.NET code for temporary basis:
1)..HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Word.Document.8\
updating BrowserFlags value to H80000024
2)..HKEY_CLASSES_ROOT\Word.Document.8\
updating EditFlags value to 65536
3)..HKEY_CLASSES_ROOT\Word.Template.8\
updating EditFlags value to 65536
4)..HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Word.Document.12\
updating BrowserFlags value to H80000024
5)..HKEY_CLASSES_ROOT\Word.Document.12\
updating EditFlags value to 65536
6)..HKEY_CLASSES_ROOT\Word.Template.12\
updating EditFlags value to 65536
Now we are migrating environment from WinXP to Win7. I have following query for Win7 environment :
We do not have rights to change registry on Win7 machine , so without changing values of BrowserFlags and EditFlags , how word docs files will always open inside webBrowser control on win7 machine? Currently I am getting popup dialog box (Open/Save/Cancel) for word doc on win7 machine at running the application.
I want to avoid it.Please help me to find the solution.
|
|
|
|
|
|
Bumping is frowned upon around here.
|
|
|
|
|
Hi guys,
I hope you had a nice start into 2012!
I've been trying to convert this^ piece of code into VB, using VS Express 2010 and #Develop. In order to avoid problems with conversion of c# 'yield' operator, I put the extensions into a DLL and set a reference to that.
The translated code of the test implementation reads like:
Shared Sub Main(ByVal args() As String)
Dim worker As New BackgroundWorker()
worker.WorkerReportsProgress = True
AddHandler worker.DoWork, Function(sender, e)
' pretend we have a collection of items to process
Dim items(999) As Integer
items.WithProgressReporting(Function(progress) worker.ReportProgress(progress)).ForEach(Function(item) Thread.Sleep(10)) ' simulate some real work
End Function
AddHandler worker.ProgressChanged, Function(sender, e)
' make sure the figure is written to the
' same point on screen each time
Console.SetCursorPosition(1, 0)
Console.Write(e.ProgressPercentage)
End Function
worker.RunWorkerAsync()
Console.Read()
End Sub
Unfortunately in VB the line
items.WithProgressReporting(Function(progress) worker.ReportProgress(progress).ForEach(Function(item) Thread.Sleep(10))) throws an exception "Expression does not produce a value" at the underlined place. There's no such exception in C# where the test code compiles and executes fine.
Having to implement the technique into my VB application, I'd like to understand where the problem arises. Could anyone of you tell me what's wrong in the (automatic) translation of the Lambda expression?
Thank you
Mick
modified 10-Jan-12 5:23am.
|
|
|
|
|
Seems to me one of your right parentheses is not at the correct position; you need one more before ForEach .
|
|
|
|
|
I changed it to
items.WithProgressReporting((Function(progress) worker.ReportProgress(progress))).ForEach(Function(item) Thread.Sleep(10)) as you said, but the same exception remains.
|
|
|
|
|
Michael Schäuble wrote: I'd like to understand where the problem arises. Could anyone of you tell me what's wrong in the (automatic) translation of the Lambda expression?
Where is the original C# code?
Bastard Programmer from Hell
|
|
|
|
|
In my initial message "this" is a link to the code (it should appear written in blue?). But it leads to the "Functional Fun" code which YOU yourself had recommended in my LINQ-to-SQL question yesterday
|
|
|
|
|
..someone having fun with your clipboard?
Bastard Programmer from Hell
|
|
|
|
|
|
Michael Schäuble wrote: I'm afraid I don't understand what you mean
My bad, I thought you were talking about another URL and that it got mixed up. Still recovering from the old year.
Translators don't like lamda's, so you might take that one out before converting the code. Would result in something like below;
AddHandler worker.ProgressChanged, AddressOf ProgressChanged
worker.RunWorkerAsync()
Console.Read()
End Sub
Public Sub ProgressChanged(sender As Object, e As System.ComponentModel.ProgressChangedEventArgs)
Console.SetCursorPosition(1, 0)
Console.Write(e.ProgressPercentage)
End Sub
Bastard Programmer from Hell
|
|
|
|
|
Ah, I've been trying that one for another reason: Most of my code is still in VB2008 which doesn't like multi-line lambdas anyway. The whole test procedure looks like this right now:
Public Sub TestProgressReporting()
worker = New BackgroundWorker()
worker.WorkerReportsProgress = True
AddHandler worker.DoWork, AddressOf DoWork
AddHandler worker.ProgressChanged, AddressOf ProgressChanged
worker.RunWorkerAsync()
Console.Read()
End Sub
Private Sub DoWork(ByVal sender As Object, ByVal e As DoWorkEventArgs)
Dim items(999) As Integer
items.WithProgressReporting(AddressOf ReportProgress) ' simulate some real work
End Sub
Private Function ReportProgress() As Integer
worker.ReportProgress(progress).ForEach(Function(item) Thread.Sleep(10))
End Function
Private Sub ProgressChanged(ByVal sender As Object, ByVal e As ProgressChangedEventArgs)
'worker.ReportProgress()
' make sure the figure is written to the
' same point on screen each time
Console.SetCursorPosition(1, 0)
Console.Write(e.ProgressPercentage)
End Sub
It still won't compile because 'progress' (underlined) is unknown.
|
|
|
|
|
Progress doesn't take a parameter, according to it's declaration. How did you resolve the fact that VB.NET lacks a "yield return" statement?
..and how about simply wrapping the C# code in an assembly and reference that from VB?
Bastard Programmer from Hell
|
|
|
|
|
From my initial message:Michael Schäuble wrote: In order to avoid problems with conversion of c# 'yield' operator, I put the extensions into a DLL and set a reference to that. According to IntelliSense 'progress' should be an integer value for 'percentProgress'.
The funny thing is that it works as described as long as I stay in C# with the Main procedure - also when using the same referenced DLL for all the extensions:
items
.WithProgressReporting(progress => worker.ReportProgress(progress))
.ForEach(item => Thread.Sleep(10));
Line 2 results in the percentage, which is properly reported to the console. So there really must be something wrong with the lambda, which obviously is too cryptic for me... Still this is exactly the part of the code which I can't reference (main procedure "TestProgressReporting") since my application is written in VB.
modified 1-Jan-12 18:42pm.
|
|
|
|
|
Eddy Vluggen wrote: How did you resolve the fact that VB.NET lacks a "yield return" statement?
perhaps with patience. Yield exists since VS2010 SP1 according to this[^].
And it is simply yield , not yield return , so for once VB.NET is less verbose than C#.
|
|
|
|
|
Hey Luc,
thanks for the hint, I'm just about downloading SP1. Still I'm afraid it wouldn't solve the problem I have: As I wrote I put all the extensions into a DLL which I'm referencing from my main VB code as well as from VB and C# test procedures. It seems pretty clear that there must be something wrong with the Lambda expressions. Would you have a look at them, please?
|
|
|
|
|
I seldom use lambda's, I probably can't help you.
If they are in a separate DLL, why aren't you using C# for them?
|
|
|
|
|
You misunderstood me. All the extension methods, which contain the C# 'yield' operator, are in a separate DLL. My application is in VB so I have to call the extensions from VB using adapted code... and the sample code (pls. see link in the initial message) is in C# where the Lambdas work.
|
|
|
|
|
Cool - I never missed the statement in VB, until this question popped up
Bastard Programmer from Hell
|
|
|
|
|
|
VB2010 has introduced sub(parameter) into the lambda specification. I haven't tested it but wouldn't the following work?
items.WithProgressReporting(sub(progress) worker.ReportProgress(progress) end sub).forEach(function(item) thread.Sleep(10)))
Lobster Thermidor aux crevettes with a Mornay sauce, served in a Provençale manner with shallots and aubergines, garnished with truffle pate, brandy and a fried egg on top and Spam - Monty Python Spam Sketch
|
|
|
|