|
I have some old .NET-to-COM code along with steps to register it somewhere. I'll see if I can dig that up tomorrow.
p.s. as I understand it, regasm has an optional argument you can pass it to generate a tlb file from the assmebly. If you do that, can you use the resulting tlb file in regsvr32?
|
|
|
|
|
<code>
Checkdate.tlb is not an executable file and no registration helper is registered for this file type.
</code>
Thanks for all the help by the way I appreciate it!
T
|
|
|
|
|
If you use a tool like OleView or some other COM object viewer, your regasm'd dll doesn't show up on the target system? It should! :-p
|
|
|
|
|
Hi Judah,
I just downloaded oleview to see, and it is there 
Just can't see it in my DB langauge. damn it. Oh and when I try to expand it in Oleview it complains at me
COGetClassObject failed.
The system cannot find the file specified.
severity: SEVERITY_ERROR, facility: FACILITY_WIN32($80070002)
T
|
|
|
|
|
Nooie, I'm afraid I've given you all the help I know how. Maybe someone else knows where you're going wrong. Yeah, AFAIK, doing regasm on the dll built with all the specs we just went over should work. I'm afraid I don't have any other ideas.
|
|
|
|
|
Is it possible to change the backgroundcolor of cells in a read only grid? The selected cell is gray (Control), but niether of the color properties in the designer that are set to the color Control by default affect this color.
Is there a way to override the default behavior of selecting the contents of a cell when it's clicked in?
Can I right align the values in the grid instead of left aligning them?
|
|
|
|
|
I'm not sure about #1, but I'd say it's very likely you can override this by either implementing a custom cell type or by overriding the grid itself.
#2, this behavior is specific to the cell type, I believe. If you want different behavior, you'll likely have to implement a custom cell type that behaves differently when click inside its contents.
#3 I'm afraid I don't know.
This page[^] has some samples & whitepapers about the DataGridView control.
|
|
|
|
|
The DataGridView's a framework generation beyond what I can use while still stupporting my clients oldest PCs. Writing a custom cell's probably more effort than I can put into it now. It might be easier to just revert that control back to a listview.
|
|
|
|
|
I have some code that I moved into a background thread that takes a considerably longer time to execute then it does if it's done in the main thread.
When in a background thread the code takes 2 minutes to execute. When in the main thread it takes 4 seconds to execute.
This seems like it's way too much of an increase to be normal.
Any ideas of what I can try to bring this execution time closer to 4 seconds while keeping it in a separate thread?
|
|
|
|
|
No idea, but it's almost certainly due to a bug in your code; this would otherwise not happen. Can you post some relevant code snippets?
|
|
|
|
|
Judah Himango wrote: No idea, but it's almost certainly due to a bug in your code; this would otherwise not happen. Can you post some relevant code snippets?
<br />
...<br />
Thread worker = new Thread(new ParameterizedThreadStart(ThreadOperation));<br />
worker.IsBackground = true;<br />
worker.Start(dataobj);<br />
m_dlgThreadProgress.ShowDialog(this);<br />
...<br />
<br />
private void ThreadOperation(object obj)<br />
{<br />
DataObj dataobj = (DataObj)obj;<br />
new ThreadObj(this).TimeConsumingOperation(dataobj);<br />
Invoke(m_delegateCloseProgressDialog);<br />
Invoke(m_delegateListViewUpdate, dataobj);<br />
System.Diagnostics.Debug.WriteLine((DateTime.Now - m_dtStartLoadingTime).ToString());<br />
}<br />
<br />
I pass in "this" to the ThreadObj so it can Invoke operations to update the progress bar dialog. If you need any more code let me know...
|
|
|
|
|
I'm pretty sure this problem is home-grown, something like this doesn't happen regularly.
Perhaps you've introduced the problem with your inter-thread synchonization?
Please post some code, otherwise we won't be able to help you.
Regards,
mav
--
Black holes are the places where God divided by 0...
|
|
|
|
|
mav.northwind wrote: I'm pretty sure this problem is home-grown, something like this doesn't happen regularly.
Perhaps you've introduced the problem with your inter-thread synchonization?
Please post some code, otherwise we won't be able to help you.
See code in my reply above, but I also tried using a BackgroundWorker instead of a Thread and I'm seeing the same result...
<br />
...<br />
m_bwWorker.RunWorkerAsync(dataobj);<br />
<br />
private void m_bwWorker_DoWork(object sender, DoWorkEventArgs e)<br />
{<br />
ThreadOperation((DataObj)e.Argument);<br />
}<br />
<br />
private void ThreadOperation(object obj)<br />
{<br />
DataObj dataobj = (DataObj)obj;<br />
new ThreadObj(this).TimeConsumingOperation(dataobj);<br />
Invoke(m_delegateCloseProgressDialog);<br />
Invoke(m_delegateListViewUpdate, dataobj);<br />
System.Diagnostics.Debug.WriteLine((DateTime.Now - m_dtStartLoadingTime).ToString());<br />
}<br />
|
|
|
|
|
What happens if you do BeginInvoke instead of Invoke?
Also, when you used a background worker, you used ReportProgress instead of Invoke, right? (With BackgroundWorker, you ReportProgress which gets executed on the UI thread asychronously.)
|
|
|
|
|
Judah Himango wrote: What happens if you do BeginInvoke instead of Invoke?
Also, when you used a background worker, you used ReportProgress instead of Invoke, right? (With BackgroundWorker, you ReportProgress which gets executed on the UI thread asychronously.)
I changed all my Invokes to BeginInvoke in the LongOperation and outside of it with no change in execution speed.
|
|
|
|
|
What happens if you remove all Invoke and BeginInvoke calls?
|
|
|
|
|
Judah Himango wrote: What happens if you remove all Invoke and BeginInvoke calls?
Same thing, if it's called from within a worker thread it's quite a bit slower. I've even done some more timings where i take out the long process out of the method that takes too much time and there is still a noticable difference between threaded and non-threaded.
|
|
|
|
|
How much slower are we talking here?
Keep in mind, multithreading does not make your application any faster on single-CPU machines. In fact, due to context switching, using multiple threads is actually slower than using a single thread on single-CPU machines.
So with that in mind, of course running on a background thread is going to take longer. What's more is, if your main UI thread is busy and you've got only 1 CPU, then your CPU is going to be constantly doing context switches to execute pieces of each thread, which is going to slow down the overall background process. If you've got a dual core machine or better, this wouldn't apply.
But you shouldn't be seeing huge differences even on single-CPU machines; only minor differences. If you're seeing huge differences, then something in your code is wrong (lock problems? sharing data between threads?), but it's impossible to tell without seeing what all the code is doing.
If all else fails, run a performance profiler on your code and see what's taking time. I use Ants Profiler which gives per-line timings and shows you your slowest methods. This should help diagnose what's taking long, which will help you figure out why it's taking longer on a background thread.
|
|
|
|
|
I ran the Ants profiler and it takes 90 seconds within the background thread and less then 1 second if it's in the main thread. This seems excessive to me to be just single CPU related but it may be, considering every line of code is being executed an equal number of times regardless which thread executes it. I'll have to run it on my dual core processor tonight and see if the results are better.
|
|
|
|
|
an 89 second difference tells me that certainly something is wrong in your code. What lines of code are taking longer? What are those lines doing?
|
|
|
|
|
I have a foreach loop that does a number of string comparisons, contains, and removes whitespace.
I tried running it on a dual core processor and there was no change.
|
|
|
|
|
Is it possible to post your project? I'm pretty sure I could fix it if I've got it here sitting in front of me.
When you run it under the performance profiler, which lines are taking longer? Surely the string comparison and manipulation isn't taking longer on a background thread?
|
|
|
|
|
Judah Himango wrote: Is it possible to post your project? I'm pretty sure I could fix it if I've got it here sitting in front of me.
When you run it under the performance profiler, which lines are taking longer? Surely the string comparison and manipulation isn't taking longer on a background thread?
Unfortunately I'm not able to send my project. But I did look at the profiler a little more and can give you some more information on the lines of code that seem to be causing the slowdown.
The dataobject that I pass into the method that takes a long time has a few properties that are List<htmlelement>. I loop through all these and analyze the individual HtmlElements contained within the list.
When I do the following:
<br />
string href = link.GetAttribute("href");<br />
*where link is an HtmlElement that is contained in the list that's a property of the passed in DataObject
or
<br />
if((currentelement.Name == destination &&<br />
currentelement.TagName.ToUpper() == "A") ||<br />
currentelement.Id == destination)<br />
*where currentelement is an HtmlElement that is contained in the list that's a property of the passed in DataObject
When I access the properties of the HtmlElement within the background thread is when the excessive execution takes place. This may have to do with HtmlElement actually being a COM object with the .NET wrapper around it?
Hopefully this gives you some more info  I appreciate your time looking into this.
|
|
|
|
|
Yes; since HtmlElement is actually part of a windows forms control, you may not want to access that on a background thread. Also, since the background thread is most likely MTA thread apartment, COM is probably wailing loudly at all this.
Instead of passing a list of System.Windows.Forms.HtmlElement to the background thread, can you pass a copy of only the data you need? For instance, from your snippet it appears you need the href, Name, TagName, and Id of every HtmlElement. So instead of pulling those from the MTA background thread, could you pull them from the UI thread, then pass those strings off to the background worker (perhaps contained in a custom HtmlElementInfo class or something)?
p.s. ToUpper() always allocates a new string. Perhaps you could use this instead:
string.Equals(currentElement.TagName, "A", StringComparison.InvariantCultureIgnoreCase)
|
|
|
|
|
I actually just started to make my own HtmlElement class which only contains the info I need. I think this will solve the problem. Thanks again
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
