|
I am trying to save it with a Save As, only the Save As is also saving it as read only. I need to use code to disable the Read Only in the converted file at Save(SaveAs) time.
|
|
|
|
|
The file cannot be saved as ReadOnly. Only when you open the file does this come into effect. Possibly your code still has the file open after it's saved??
|
|
|
|
|
Hi dave. I realize the read only cannot be saved.
The file loaded is read only (not Excel protected). I need to save it as another name (easy) but remove the "read only" setting (hard part) in code.
For some reason, the new file, although saving under the new name as I have wished also carries the "Read Only" setting from the original file that was copied.
I need to change that during the "Save As" part so as to remove the "Read Only" setting on the newly named and saved (SaveAs) file.
It needs to be done in code also, not via manual access from the windows explorer.
Thanks for your time and efforts so far Dave.
|
|
|
|
|
frankiebaby2 wrote: but remove the "read only" setting (hard part) in code.
Last time: THERE IS NO READONLY SETTING! The file is only determined to be "ReadOnly" when it is loaded by Excel. If the file is already open by another process, or another instance of Excel, the file will be opened as "ReadOnly". THERE IS NO SETTING IN THE FILE THAT DOES THIS.
If the file was just saved as a new filename, but you haven't closed it in your code's instance of Excel, ANY ATTEMPT TO OPEN IT IN ANOTHER INSTANCE OF EXCEL WILL RESULT IN IT BEING "READONLY".
|
|
|
|
|
I am working on a project that requires me to extract (and record for later use) the WORKnumber which is always stored in the first line of a text file (WO*1234). I am tring to find a way to dynamically replace this number with WO*9007, but I always want to record the original work number before replacing it. I am fuzzy on how to write code for this. Can I get some help on this? I am a relative newbie. Thanks
|
|
|
|
|
its not 100% clear if you want to write a new file with the same name, and the replace WO*9007 entry as the first line or not .. so Im going to proceed on that assumption. You need to write code to do the following steps :-
0) declare and set a line counter variable to 0,a string var and set to "" (empty string)
1) rename the original file - include .tmp or .bkp as the extension
2) open the renamed file from (1) for reading [input]
3) open a new file with the original name for writing [output]
4) construct a loop to read the input until End-of-file
5) read a line from [input]
6) increment a line counter
7) if the line counter variable is 1 and the line contains WO*1234 substring/extract out the WO*1234 part, replace it with WO*9007, and write it to [output]. Store the WO*1234 part in the string variable - that could be about 4 simple steps
8) write every other line to [output]
9) (eof of file)/loop
10) close input
11) close output
12) if no errors, delete the .tmp or .bkp file
what do you think about that set of instructions ? its all doable, there may be some improvements, but its simple steps. Now, you code them - come back to us when you have code you need checked.
'g'
modified on Saturday, January 24, 2009 12:40 AM
|
|
|
|
|
OK. I got that. What I had to do was to change my design approach; rather that extract the number, I provided a 2nd text box for users to record the number in th applet. Now, I want to add "REF 007" in a new line immediately after every occurence of "PER*980" in the text file (it will always occur multiple times).
Here is what I have coded so far; but nothing happens:
Dim refNum As New IO.FileInfo(lblWorkFile.Text)<br />
Dim writer As IO.StreamWriter = refNum.CreateText()<br />
writer.WriteLine(txtWorkDetail.Text)<br />
writer.Close()
I would at least think a new blank line would be inserted.
|
|
|
|
|
I've created a big program (2.5M) and it's loading slowly on startup. Could someone please point me to ideas on how to improve this. Many of the subroutines are rarely or never needed by many users. So I'm thinking of putting them in separate .dlls. Would that help?
Tia
|
|
|
|
|
Breaking the application to smaller pieces using dll's would help.
However, if the application size is 2.5MB and it's starting up slowly, I would guess that the problem is somewhere else. Perhaps you're doing lot's of initializations in the beginning.
Also you could check the compiler settings and let it do optimizations and remove the debug constant.
|
|
|
|
|
If you've got a ton of code in your startup form or an excessive number of controls on it, then this is going to be a problem. To partially solve the problem of a large code-base, you can move non-UI involved code to another class (class library). If you have an excessive number of controls, there's nothing you can do about it except re-design your app. You can also try running NGEN on the installed application to generate the native code assemblies for that machine, but don't count on a huge performance gain from this.
|
|
|
|
|
Thanks to you both. So the code in the class libraries is not loaded by my program until it is needed, saving time on startup? Is that the idea?
|
|
|
|
|
Yep. entire assmeblies are not compiled when needed. The JIT compiler only compiles what is needed at the time, if it hasn'y already been compiled. You can have an assembly with (bite-my-tongue) 1,000 methods in it, so only them method being called will get compiled at the time it's needed. The remaining methods won't be compiled until they're needed.
|
|
|
|
|
But that last comment, Dave, makes it sound as if this is true for all methods, not just methods in the accompanying class libraries. So why is there an advantage of moving code from the .exe into the .dlls?
|
|
|
|
|
Having everything in a monolithic .EXE file takes the loader forever to load and process, setup the runtime environment (.NET CLR), pass control to the CLR, which reads what it needs, compiles the necessary methods, if not already previously done, and calls the entry point of the code, which will call other methods in the code, and finally getting around to calling InitializeComponent for all of the controls, again, more compiling, and creating an instance of the form.
There's a LOT that happens before you see your startup form...
|
|
|
|
|
Dave Kreskowiak wrote: There's a LOT that happens before you see your startup form
And that's not even all 
|
|
|
|
|
Hi
I'm trying to use the system.printing namespace to get the status of print queues on a print server. Unfortunately the only status I ever get for any queue is "None".
Here's the code:
dim myPS as PrintServer = New PrintServer("servername")
dim myPrintQueues as PrintQueueCollection = myPS.GetPrintQueues()
For Each pq as PrintQueue in myPrintQueues
pq.refresh()
'output pq.name
'output pq.QueueStatus.ToString
Next
I must be missing something obvious. Can anyone give me a pointer.
I previously posted this question to the .NET framework forum with no luck so reposting here.
Thanks.
|
|
|
|
|
The code looks good, though I can't test it right now.
There are two possibilities. The user account you're running the code under does have sufficient permissions to get the print queue status, which is unlikely. And, the printer driver is under no obligation to update the status with the print server. So, it's entirely possible that the status really is None, even though it's doing something.
|
|
|
|
|
I've been programming for 5 years and I can't believe something this easy can have me stumped! 
I am trying to append the text in a textbox to the next line...
e.g. "This is line 1"
"This is line 2"
"This is line 3", etc.
I set the textbox to accept 'return' and set it to multiline, but whenever I add text to it, it just won't add anything in the next line, they all follow on from the previous line.
I use the chr(13) character to indicate the start of a new line, but that doesn't help either. 
My code looks like this:
Dim i As int16
for i = 0 to AdvertList.Rows.Count - 1
'get all the details here...
NewAdvert.AppendText(Chr(13))
NewAdvert.AppendText(advertText)
Next
What am I doing wrong? 
Please help?
Thanks in advance 
|
|
|
|
|
Myabe try VbCrLf instead of Chr(13)
|
|
|
|
|
Woah, it worked...
You don't have a damp cloth for me to wipe the visible embarrassment from my face? 
Took me 40 minutes to write 300 lines of code, and a further 30 minutes trying to get around this simple problem. Damn, I feel so stupid!
Thanks ![Rose | [Rose]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/rose.gif) so much for the quick response, saved me a few more wasted minutes of redness. 
|
|
|
|
|
No problem, glad I could help someone else for a change instead of other people helping me 
|
|
|
|
|
Glad to help my first person on this forum.
|
|
|
|
|
|
I would suggest using Environment.NewLine instead. The vbCrLf constant is platform specific, and a backward-compatiblity holdout from the old VB6 days. There's no guarantee that it will stick around in future versions of the .NET Framework.
|
|
|
|
|
More appropriately, Environment.NewLine.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
