|
Hello,
I can write code to read and write to excel and word.But I face problems with versions.A certain version works at my end and doesnt work at the client end.
I have included Microsoft Excel 12.0 Object Library at my end and found that the client didnt have this library .He had Microsoft Excel 5.0 Object Library .So I coded According to version 5.0 but still at the client end I am getting the error saying the Interop file doesnt exist.It works fine with me.
Can you tell me how do I nail down version problems and Is the COM coding for Microsoft Excel Word different for different versions.
Thanks
Pritha
|
|
|
|
|
prithaa wrote: saying the Interop file doesnt exist.I
If your code creates an interop file, that file needs to be available on your client's system.
My signature "sucks" today
|
|
|
|
|
Thanks for your reply
Which files do I need check ? I am sending the exe file of my working project.
Pritha
|
|
|
|
|
Have a look in the bin folder. Do you see any interop files?
If yes, then you would need to include them along with your exe.
My signature "sucks" today
|
|
|
|
|
Excel 5.0 came out 'way back in 1993 IIRC... I wouldn't be surprised if you had some trouble getting it to work - there aren't any Primary Interop Assemblies for it and working with it directly through COM can be iffy. If your Word and Excel files are not too complex, I would advise you to use NPOI[^] to read from and generate the files. NPOI does not depend on Word or Excel in order to work - so there are no version problems, and you don't even have to worry if the machine your code is running on even has Office at all. It supports formatting like fonts, font styles, colors, tables, formulas, col and row sizing and autosizing, document properties, etc.
|
|
|
|
|
Hello,
Yes I have Interop files
Interop.Excel.dll
Interop.Microsoft.Office.Core.dll
Interop.Microsoft.Office.Interop.Excel.dll
Interop.VBIDE.dll
I should send all these files alongwith exe
thanks
|
|
|
|
|
In the following code, which I have found to be common practice amongst the examples I have found on the web, the WebRequest class is instantiated like it's a regular class yet it's an abstract class. Underneath the hood, the http object is a really a HttpWebRequest object, but doesn't this defy the principle that you cannot instantiate abstract classes through it's syntax? This is the line that doesn't make sense to me: WebRequest http = WebRequest.Create(url);. WebRequest (abstract class) is being instantiated as object http. If the underlying class that is being instantiated is the HttpWebRequest than shouldn't that only be allowed?? such as HttpWebRequest http = HttpWebRequest.Create(url)?
class ScanUrl
{
public StringBuilder Scan(String u)
{
StringBuilder sb = new StringBuilder();
Uri url = new Uri(u);
WebRequest http = WebRequest.Create(url);
WebResponse response = http.GetResponse();
int count = 0;
String key, value;
for (count = 0; count < response.Headers.Keys.Count; count++)
{
key = response.Headers.Keys[count];
value = response.Headers[key];
if (value != null)
{
if (key == null)
sb.Append(value + "\n");
else
sb.Append(key + ": " + value + "\n");
}
}
return sb;
}
}
|
|
|
|
|
Jeff Kissinger wrote: the WebRequest class is instantiated like it's a regular class
Not, it's not. The WebRequest class exposes a static method (no instance required!) that creates an instance of HttpWebRequest, which inherits from WebRequest. Since the returned object inherits from WebRequest, you can use the WebRequest methods and properties since they are implemented by the HttpWebRequest class.
Jeff Kissinger wrote: but doesn't this defy the principle that you cannot instantiate abstract classes through it's syntax
No, since you're not instantiating the WebRequest class. Your instantiating an implementor of it, namely HttpWebRequest.
Jeff Kissinger wrote: If the underlying class that is being instantiated is the HttpWebRequest than shouldn't that only be allowed??
Read up on inheritance. You can treat the returned object as any type in its inheritance chain, all the way up to System.Object. The interitance chain for HttpWebRequest is:
System.Object
System.MarshalByRefObject
System.Net.WebRequest
System.Net.HttpWebRequest
|
|
|
|
|
And read up on the Abstract Factory and Factory Method design patterns.
|
|
|
|
|
Thanks, both of you for your great answers and cluing me in on the Abstract Factory. I've never heard of the Abstract Factory in the official Microsoft courses that I took. After finding some books and websites on this topic yesterday, I was able to understand the implementation. I have to say the topic isn't listed in most C# .NET books and when it was present, it was pretty vague.
I found it in sufficient detail in the following books:
O'Reilly - C# Design Patterns 3.0
Apress - Pro .NET 2.0 Code and Design Standards in C#
If you know of any other great resources, please let me know.
Thanks!
|
|
|
|
|
Almost in every site that I searched today, it is advised that BeginSend is more efficient on server than having a separate thread for each connection.
MSDN on the other hand says:
"When your application calls BeginSend, the system will use a separate thread to execute the specified callback method"
Now if each call will create a new thread, how is it more efficient than having just one thread available for send?
Thanks a lot in advanced.
"I hope you live a life you're proud of. If you find that you're not, I hope you have the strength to start all over again."
- I wish I knew who is this quote from
|
|
|
|
|
What kind of server and connection?
|
|
|
|
|
A TCP socket server and socket connections to it. Probably many connections.
"I hope you live a life you're proud of. If you find that you're not, I hope you have the strength to start all over again."
- I wish I knew who is this quote from
|
|
|
|
|
Personally, I prefer to use my own threads. I have never used the Begin... methods.
|
|
|
|
|
I probably didn't ask a true question (according to the title).
I am designing a socket server. Some clients will connect to it and transfer data to and from this server. Connections must be kept alive for long times and there will probably be as much as hundreds of connections.
I was comparing different ways to do it and was asking myself which one is better. There are blocking vs. non-blocking solutions. To use blocking API calls and keep server ready for more accepts, a common approach seems to be having one or more threads or processes per connection. Blocking calls like Receive and Send will be handled in those threads/processes.
On the other hand many people suggest that this method is not efficient so a better approach is to use asynchronous APIs like BeginSend.
This raised the question in my mind that which one is really more efficient?
"I hope you live a life you're proud of. If you find that you're not, I hope you have the strength to start all over again."
- I wish I knew who is this quote from
|
|
|
|
|
It doesn't start a thread, it uses one from the ThreadPool
|
|
|
|
|
How much different is that considering resource consumption? Is there a good benchmarking for that?
"I hope you live a life you're proud of. If you find that you're not, I hope you have the strength to start all over again."
- I wish I knew who is this quote from
|
|
|
|
|
It's almost like starting a new thread vs ThreadPool.QueueUserWorkItem, but not exactly
|
|
|
|
|
In my experience, using BeginReceive etc does not cost you any throughput (at reasonable speeds) - but that's all I know, I don't do much socket programming
|
|
|
|
|
Thabks harold.
Your help is appreciated. 
"I hope you live a life you're proud of. If you find that you're not, I hope you have the strength to start all over again."
- I wish I knew who is this quote from
|
|
|
|
|
When you use your own threads, you are in charge. You can do whatever pleases you; the price for that is the expense of a thread. Each thread needs its own context, consisting mainly of a stack, which by default takes 1MB of memory.
When you use asynchronous operation, you are relying on how they implemented that. .NET asynchronous operations use ThreadPool threads, which is a pool of threads with certain characteristics. The big advantage in using ThreadPool is you can get the same activity covered with fewer actual threads, which is great especially when you would need hundreds or thousands of them, e.g. because you have that number of sockets, or timers, or serial ports.
There are disadvantages too, of course. You can't change most of the ThreadPool characteristics, e.g. stack size, thread priority, etc. And you can't change the dynamic behavior of the ThreadPool; it will start with only a few active threads, and the way they implemented it, it will detect heavy load and add more threads at a fixed rate of only 2 per second. There are some parameters one can set, but they are few because the ThreadPool is used by .NET itself, hence it needs to get launched long before your first line of managed code executes.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
Thank you so much. Detailed and informative.
For what I'm doing right now, using saync functions seems to be good enough.
Truth is that we don't want connections for the sake of just connections. So after connections established and when data transfer starts there will be threads and all those context switching stuff. If the only benefit is that it uses thread pool, I think we can use it if we needed. Although they probably have better performance in their thread pool. They most probably use WinSock async APIs and those native calls must be very fast.
Your answer helped me a lot.
Thank you again.
"I hope you live a life you're proud of. If you find that you're not, I hope you have the strength to start all over again."
- I wish I knew who is this quote from
|
|
|
|
|
you're welcome.
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles]
I only read formatted code with indentation, so please use PRE tags for code snippets.
I'm not participating in frackin' Q&A, so if you want my opinion, ask away in a real forum (or on my profile page).
|
|
|
|
|
Hi, I was just trying to figure out how to get the C# platform to give me standard Unix Time (ie the number in seconds since 12:00 AM January 1, 1970), which is pretty universal (i thought) throughout programming. If anyone knows how to get this time it would be very useful. Thanks,
|
|
|
|
|
jojoba2011 wrote: which is pretty universal (i thought)
Not since ISO 8601 came out. 
Quick-and-dirty extension methods to do that:
namespace PIEBALD.Lib.LibExt.UnixTime
{
/**
<summary>
Library of extension methods that convert to and from UnixTime
</summary>
*/
public static partial class LibExt
{
private static readonly System.DateTime Epoch ;
static LibExt
(
)
{
Epoch = new System.DateTime ( 1970 , 1 , 1 , 0 , 0 , 0 ) ;
return ;
}
public static int
ToUnixTime
(
this System.DateTime Time
)
{
return ( (int) ( Time - Epoch ).TotalSeconds ) ;
}
public static System.DateTime
FromUnixTime
(
this int UnixTime
)
{
return ( Epoch.AddSeconds ( UnixTime ) ) ;
}
}
}
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
