If your point is that the Microsoft Corporation, as a business, is doing fine, then I agree with you. Afterall they are the 5th largest corporation (measured by capitalization). And yes, their business is mostly the enterprise side. However... Apple came from nowhere to become the SECOND largest corporation - so no one should think that the consumer side isn't relevant. MS has got the enterprise side sown up, for sure. However every corp needs to GROW to survive, and MSFT is struggling to GROW. It appears that they want now to shore up their mobile and consumer devices side of things - can you blame them? Not only is MSFT struggling to gorw, they're also struggling with entry into the Mobile Space and with Developer and Consumer Mindshare - and mind share is so very important. It's what propelled Apple into #2 position (behind Exxon Oil). So when you hear/read that MSFT is yesterday's news and their offerings are being ignored and hated, what you are witnessing is peoples' sentiment - and this is a clue about Mindshare. These days a tech firm can fall in as little as 5 years. It may have taken 20 years to kill Motorola, or 10 years to kill Nokia, but the horizon is shorter today and Microsoft has to do everything they can to grab Mindshare in order to secure their future. I still believe that with their enormous enterprise position and almost bottomless bags of cash that they will get over the current problems with their Win8 tablet sales - even if that picture is hard to see in the near term - but so far I see absolutely NO progress with Mindshare. People routinely mock Microsoft and their products. On Sept 10th when Apple had their showing of new phones I was looking through Flipboard and I couldn't help but be aghast that EVERY SINGLE tech story was about Apple and their new phones. Now THAT'S Marketing power, my friends, and without Mindshare that's not possible. I think Microsoft's products are good enough (for them to have a good business) but the company absolutely SUCKS at Marketing and Promotion and they should really STUDY Apple in order to get a clue for what to do. And if they really want to increase Mindshare then they need to clue in that people hate them for a REASON. Yeah, Karma's a biotch.

OK I ran the ANALYZE statement but it doesn't show anything. Any other ideas?

Thx for the reply. No, I did not explicitly add any indexes (indices?). I just did a "CREATE TABLE..." and followed it up with Inserts and Selects. The Selects work fine. The Inserts don't. I'll take a look with that ANALYSE command that you reference.

Hi All, I am _occasionally_ (inconsistently) getting "Attempt to write to read only database" problems with System.Data.SQLite. Googling this issue brings up lots of pages talking about file/folder permission issues (especially with web servers). I have a Windows Forms App and no web server is involved. Additionally, this problem happens inconsistently (like with every 20 Inserts) and I've got my database in %APPDATA%\MyApp folder (where %APPDATA% is set to the ...AppData\Roaming folder on my data drive). I have no reason to suspect a file/folder permissions problem. I added a delay to each Insert and I observe that the number of, and likelihood of getting a "Attempt to write..." error is directly related to the length of the delay - a delay of 1 second after each Insert seems to *almost* completely relieve the problem. Do I have a misconfiguration problem? Searching the net shows lots of positive comments for the stability and correctness of System.Data.SQLite and no solutions suggested except for file permissions config, but my system behaves like SQLite is tripping over itself. There are no other file operations (outside of the OS activity) happening at the same time. I'm out of ideas - help! I'm using C# vs2008 (I think it's .net 3.5). It was a Win7 box but now it's a Win8 box (no difference for this issue).

I'm not familiar with BindingList. I took a quick look at the link but am unsure of its benefit here. Thx for the heads up, though.

Wow, wonderful article. Again, the timer that I'm using is the System.Windows.Forms.Timer one (I'm cut&pasting this from the .Designer.cs file - and I don't see any other timers) Thx for the article. I'll look at all this in a bit.

Hmmmmm... I am using a System.Windows.Forms.Timer. Isn't that the one you are referring to that doesn't use a separate thread? Okay, now I'm confused. My code works if i execute it from a button. It works if I invoke it thru a delegate. Other than that nothing happens.

Dave Kreskowiak wrote:

Then quit bitching...

Your discourse is not civil, but constant.

A SendMessage() call works between threads... at least I thought it did. Thus I thought this was a .NET constraint. If it's not a .NET new constraint then I just learned something.

Dave Kreskowiak wrote:

go write code for Linux.

No! (so there)

Wow! You have such a myopic view of what's going on.

I don't think so. Let's revisit this one more time. So I'm supposed to put all code that modifies a control into wrapper code that calls invoke and this wrapper code ends up being a conditional test to see if invoke is required and then recursively calling the same function thru a special delegate that is created just for that invoke call. I've repeated my example code below:

private delegate void RefreshLbxDg8();
private RefreshLbxDg8 _refreshLbx;
...
_refreshLbx = RefreshLbx;
...
public void RefreshLbx()
{
if (lbxQuotes.InvokeRequired)
{
lbxQuotes.Invoke(_refreshLbx);
}
else
{
lbxQuotes.DataSource = null;
lbxQuotes.DataSource = _quotes;
}
}

All this is required in order that the code gets executed on the GUI thread. Now, I'm simply updating a textbox with a sample (number). Nothing else. I guess I could have stated my point better: yes, it is an asynchronous system and it is *possible* that a WM_PAINT would get processed while the textbox text is changing. I am aware of this. My complaint was that .NET designers used this sledgehammer solution to prevent any presentation rendering mishap (ie. my number is rendered while it is changing) by constraining all code to execute on the GUI thread. So this means that for every single interaction with any control - and there's a LOT of them, I'm supposed to write wrapper code around everything, and this wrapper code involves defining and creating delegates and rewriting all my code to include a conditional statement which tests for this invokability. AND YOU'RE FINE WITH THIS. Me, I think this is a horrible and terribly primitive solution and design. It would be better to leave me with using SendMessage() to inject my action into the GUI's Message-Loop. And that's not to mention that the compiler gave no warnings, there was no runtime error, the code SILENTLY failed, and I had no idea that the timer implemented its actions with a (hidden) separate thread. I am LESS than impressed.

Kuel. I like that you can use a List<> of Key/Values for a ListBox. Did not know that. Then can use the DataMember, ValueMember flexibility. Thx. However... You are executing the update from a button_click Method - thus the code is executed on the UI thread - thus it will work. My problem is that I am executing from a timer handler - because I need the update at regular intervals (taking samples) - thus the handler is on a different thread and thus, when executed, silently does absolutely nothing. Thx for the code. Educational. (and 'yes' I got it working)

My thanks to all who responded. >>

You can NOT so much as touch ANY part of a control from a thread other than the one that created it, the UI (or startup) thread. This is where your entire problem comes from.

My confusion was mostly that I was not trying to run a Method at all - I was just changing a Property (or what I thought was DATA). Upon more consideration, I realized that a Property is just syntactic sugar over a procedure call, anyway, so the "you can't run code from a different thread" rule applied even changing a Property. However, I am mystified as to WHY this rule "no touchie from different thread" even exists. Sure, if I'm trying to update a TextBox from other threads then there *could* be confusion and a random mix of characters added from the various threads due to the asynchronous timing of the code in the different threads. Yes, there *could* be... it is *possible* - just like I could really mess up a data structure if I update it from many threads without synchronization. But that is exactly what multithreaded coding is all about - synchronizing the use of common data structures (at least it is a major issue, if not the biggest issue). But why would the compiler assume that I am needing multithreading synchronization when updating a Textbox? The truth is, I am doing something at timed intervals - I am using a timer. It just so *happens* that C# chooses internally to implement a timer via a separate new thread. That is not *my* problem. I'm not trying to append text to the textbox from 17 different timers or asynchronous threads. I'm simply trying to update a textbox at constant intervals - in this case the system chooses to do this via ONE (other) thread. Suddenly now I have to become fully knowledgeable about multithreading and delegates and "invoking", etc. BAH! Unnecessary, unneeded, unwanted complexification. Aside from all that, I especially did not appreciate that the code simply failed to do anything - I got no compiler warning/error nor any runtime problem. My dialogbox simply didn't update. Then I had the fire up The Google and go searching for why it didn't work. My first real clue was that if I caused the update to happen from the very same function, via a click of a button on the UI, then it worked. Whaaa? My code definitely worked, but only if executed via a pushbutton. I've coded for years, and I'm teaching myself C# now, and "yeah" this is a noobie kinda problem, but geeeez what an unnecessary timewaster. Okay, 'nuff whining. Thx to all who re

Wow but this is weird. Okay, I found the solution because I tried the recommendation given below:

lbxQuotes.DataSource = null;
lbxQuotes.DataSource = _quotes;
lbxQuotes.SelectionMode = SelectionMode.None;
lbxQuotes.SelectionMode = SelectionMode.One;

That is, I added the SelectionMode two lines... and this caused (only once) a "from different thread" exception. Weird, I'm NOT running a method - I'm changing data... hmmm... I wonder if the DataSource is instead a Property (which secretly runs a method). D'oh! Okay, so the solution was to create a delegate in the main form, for the RefreshLbx method, and have the RefreshLbx method recursively call this, as below:

public void RefreshLbx()
{
if (lbxQuotes.InvokeRequired)
{
lbxQuotes.Invoke(_refreshLbx);
}
else
{
lbxQuotes.DataSource = null;
lbxQuotes.DataSource = _quotes;
}
}

with the _refreshLbx delegate defined in the form's class as:

private delegate void RefreshLbxDg8();
private RefreshLbxDg8 _refreshLbx;

Then just init the delegate in the form constructor (after the InitializeComponent() call):

    \_refreshLbx = RefreshLbx;

Now I am able to update the listbox contents from a timer handler.

Well, I'm plum out of ideas. I've got a listbox with a List<> for its DataSource. When I init it - before the form is displayed, it works. But not after that. I am modifying the List<> contents and then I run:

public void RefreshLbx()
{
lbxQuotes.DataSource = null;
lbxQuotes.DataSource = _quotes;
}

where _quotes is the List<> Now here is where it gets weird. I put a button on the form - here's its handler:

private void btnRefresh_Click(object sender, EventArgs e)
{
RefreshLbx();
}

So that when I click on the button then the lbxQuotes listbox is properly updated. But in the modification code - where I call RefreshLbx() directly, nothing happens. I even tried invoking btnRefresh_Click() in the code, but alas could not find the magic. Oh one other thought - the modification code is in a timer event handler - could this be a problem of trying to modify a control from a different thread? All I am doing is changing the List<> contents and then reseting the DataSource. I must be missing something to kick the listbox to redisplay, or something... HELP!