Hello Trent,

sometimes it worked as expected, somtimes I got a cross-thread error.

Accessing the combobox from inside the DoWork-Method is causing the error. The combobox is an element instantiated outside the DoWork thread of the BackgroundWorker and therefore lies at another thread, I guess. I don't know why it is working sometimes, but I don't know at all why Windows is working sometimes, or not...

Thank you very much, this will be great!

But could you localization issues also take into account? It would save me (and other international customers too) tons of work...

Thank you very much and friendly greetings,

Ralph

That would probably be a good idea.  Just to make sure that you are aware...you can create your own deployment dialogs right now as we speak.  In fact, the framework comes with a sample showing how to do this so you can create your own deployment environment for an install or whatever need you have there.  This is what we do for our medical software as well as the SF installation.  This is just a thought so you could move forward without having to wait on me

Hi Trent!

Yes, Trent. I'm aware and that's really cool.

But it would be even cooler, not to have to do that.

Please don't get me wrong, SF is a great framework and I love it. I tried a few others and found SF seems to fit my needs best, especially the data deployment tool. This tool makes SF a real time saver when installing data for applications. Unfortunately this really important tool is not localized, which causes me to 'create my own deployment environment for an install'. It would be really great not to have to do that. I hope I can put my own development environment into a trash-can some time soon...

Thank you very much and friendly greetings,

Ralph

Hello,

sorry for asking this again, but it crashes on two of my machines (Intel and AMD) even with the newest beta:

 This is what I found at http://msdn.microsoft.com/en-us/library/system.componentmodel.backgroundworker.aspx

Note:
You must be careful not to manipulate any user-interface objects in your DoWork event handler.

Seems to me like manipulating the combobox is causing the problem. A little bit above in this thread I sent you already what could be done to avoid the problem. It would be very nice if you would think about to fix it in some of the next betas or at least the next final of StrataFrame.

Thank you very much! :-)

Ralph

Ralph,

It seems to me that you already know what to do   This sample was written a long time ago prior to the cross-thread issue check within VB.NET as well as C#.  We are very familiar with how threads and events work and what must be done in regards to talking to the main thread via a delegate.  Thanks for letting us know that there is a potential issue in a sample.  We will look at this prior to finalizing the 1.6.6 build.

Just FYI, the database migrator class is 100% thread safe and is something that is used extensively on a daily basis.  So there is not an issue within the framework in this regard.  But in any case, we will add this to the "to-look-at" list before the final release.

Dear Trent,

yes, I know already what to do. But could it actually be the reason to buy a framework to have it to fix by my own? I don't think so, Trent. Sorry. I couldn't imagine that the reason to buy a framework also could be to write the built-in dialogs and functions by myself to have them functional, translated or something else. If I would think so, I would write my own framework, wouldn't I? ;-)

The posted code is not out of an old example, I took it directly from the newest beta-source code dated July, 24. 2008 directly downloaded from my download area at StrataFrame. Sorry, Trent, would you please be so kind and have a look at it?

So I think you could easily fix the problem, If you like to do.

Again, I don't talk about a sample here. I talk about the source of the framework.

Please have a look at MMDeployMain.vb, Private Sup LoadSQLServers(), which is called from inside the sqlWorker.DoWork()-Method and because of this runs inside the thread, manipulating a GUI-element outside the thread. Sorry, I don't know how to express myself better in english, but I hope you understand what I mean?

That's great, I'm sure there was only a misunderstanding. :-)

OK, Trent. Than I have only hallucinations and the errors I sent to you are only in my imagination, I must be delirious. Sorry for annoying you with my incompetence and ignorance. I beg your pardon for my mistake. All right?

Let me tell you something, an old german people wisdom: 'If you can not find any mushroom in a wood, that means not that there are no mushrooms!'. Maybe there is something similar in english.

This old wisdom get's very funny if you interchange 'mushroom' with 'bug' and 'wood' with 'software'... ;-)

If you think so... But I can't help me, I get errors...

Please, Trent, not at the 'to-look-at' list. At the 'urgent-to-fix' list, please! :-)

Thank you very much and friendly greetings!

Sincerely yours,

Ralph

Ralph,

There is absolutely no need for caustic or "smart" remarks.  We always strive to provide excellent support and if there is an issue within the framework...we have NO issue addressing it and getting a fix out there.  In fact, making the change once I actually found what you were looking at took less than 30 seconds!  So there has been far more emotion, frustration, and strain wasting on this forum thread than ever was placed towards comin up with a resolution.

You keep telling me that it is not the sample, but if you will look at this thread, your subject reads, "SampleDataInstallerClass."  So if you weren't referring to a sample...then it would be a good idea to post where the error actually is that you are running into versus encrypting the message

First of all, the problem that you are having is not in the DatabaseMigrator class anyway!  Which as I mentioned, is 100% thread safe.  After re-reading your post several times and trying to understand where you were actually having the problem, the issue was in the MDDeployDialog class (again not the SampleDataInstallerClass or the DatabaseMigrator class as you had mentioned).

Also, in the future, please provide the class or a stack trace versus trying to just explain the issue which will take all of the emotion and frustration out of the formula as well as provide static facts which can lead to a resolution.

Finally, you and I had discussed through email this dialog and I informed you that this dialog will be made obsolete in a future release as this dialog will be re-worked to follow themes and to be localized.  This is why we provide the ability to create your own deployment dialogs using the DatabaseMigrator sample as well as provide samples.  The DatabaseMigrator class is where all of the work is done...not the MDDeployDialog, which only collects SQL information and allows a package file to be selected, which in turn uses the DatabaseMigrator class.  If you had looked at the DatabaseMigrator sample which comes with the framework, you would have seen that you could have created your own deployment dialogs very quickly and easily as this MDDeployDialog is not really something that was ever intended to be used largely in the field as it requires the end-user to have to know too much.  Most of this should be masked from them preventing deployment issues.

At any rate, I have already spent far more energy than was ever necessary on a 30 second fix...it will be in the next posted update.

Trent,

OK, I see your point and where I did the mistake. I used the old thread with the old problem and wrote in the message, posted yesterday @ 12:11:45 PM: 'sorry for asking this again, but it crashes on two of my machines (Intel and AMD) even with the newest beta:'

Do you really mean the 'newest beta' could be an old example? Then I would have to think hard about my english...

And I took the SampleDataInstallerClass while I'm not using my first framework and I really don't want to be asked over and over again if I can reproduce the errors with the examples coming with a framework.

As mentioned, english is not my native language. But I do my very best to express myself and to improve my english. Sorry if my best is not worth a penny, but it's all I have.

So let's get back to the issue:

I really hate it to be told there is no problem when my machines are crashing over and over again, reproducible at the same point with a cross-thread-error. And I really hate it to post an easy fix (OK, it was a fix in C# and surely not the best way to fix the problem), but only to hear that 'there is no problem at all, but thanks for your efforts'. More than that I hate to be told over and over again something like: 'We are very familiar with how threads and events work and what must be done in regards to talking to the main thread via a delegate' while my machines are crashing with cross thread errors.

Or even better: '...you can create your own deployment dialogs right now as we speak.' And I got told that not only for dialogs. If I would plan to write my own database-deployment-dialogs, my own localization and so on among other things I got told I could easily do by myself, I would not know why I should spend money for a framework.

Maybe the subject of the thread is not a subject which describes correctly the kind of the problem or where it lies. But if you had have a look at the posted code two steps earlier in this thread you would have seen that it can't be code out of an old example, but that it is actually source code of the newest source code of the framework. Or can you show me any old example with a method 'Private Sub LoadSQLServers()' which is not identical with the source code of the framework like it was at July, 24?

Again, I beg your pardon if I expressed myself wrong or took the wrong thread or subject to get you knowing about that the problem persists even with the newest beta.

You wrote me above in the thread: 'I ran the C# sample that gets installed with the framework (instead of the one from the forum) and did not have any issues.' One or two messages later in the thread you wrote me: '...you are getting a cross-thread violation, which we have run into an issue recently where one machine would get the error and not another.'

So what do I have to think now? Is there a problem which you can reproduce or not? Am I stupid? Am I hallucinating problems when I see my machine crashing? Ah, I should stop smoking that damned stuff...

What do you think what I posted for what Microsoft tells about accessing the GUI while on a thread? To annoying you while looking at my machine crashing with a long known cross-thread-error I told you a long time ago in many messages?

And that's not the only problem I am reporting only to get told something like: 'There is no problem, the framework is used for apps running in production environments world wide without any issue'.

Am I dreaming? Should I believe that I am actually the only one at the whole world with a sometimes wired browse dialog? Is it really true that I have to do all I can do to get you to reproduce an error which takes only three mouse clicks to reproduce? Do you know what you wrote me the first time I told you about the wired browse dialog throu email?

Yes, something like: There is no problem at all, the browse dialog is used by many, many people out in the field without any issue.

Dear Trent, please tell me what do I have to do not to annoying you but to get token serious when reporting bugs?

Do you remember what kind of fight I had to fight to get you to understand what I mean at the newly introduced Search Field Identifier? I gave you an example how Microsoft it does in VS to get you understand the need of numbering the new identifier and you wrote me: 'Well, the reason we don't do that by default is for backward compatibility..and core logic.'

What? Backward compatibility for a newly introduced identifier nobody could have ever used? What backward compatibility? I didn't understand. I really didn't understand. I do not understand 'til now. Do you? Can you tell me what kind of backward compatibility the Search Field Identifier should have? I can't imagine of anything...

And core logic? What kind of core logic? I think I need an example...

But at the good end you wrote: 'I think that I get where you are coming from.  I agree that it would be easier to increment the name for subsequent column names.  This would be a farily easy thing to implement in a future build.  I will add it to the list.'

Thanks god, Trent got me right, I thought. :-)

But why took it so long time an so hard efforts to get him to that idea that it 'would be easier to increment the name'?

Did it not even VFP this way? Numbering identifier automatic?

Trent, I think there is a lot going wrong with our conversation. It seems I'm not able to communicate in english. I should stop it, I think. Maybe I should stop programming at all. It seems someone spoke a spell at me to find any bug, but not to be taken serious when reporting.

OK, Trent, let me beg your pardon again if I did or wrote something stupid. But please understand that I'm tiered of writing 4 or 5 messages to get you things done that take 'a 30 second fix'

You took the words right out of my mouth, my words, dear Trent, my words...

This thread was started by me in january. Can you tell me why it took so long time and so many messages when it is only about a 30 second fix?

Ralph

Trent is unavailable at the moment, so just to answer your most pertinent question: It took this long to solve the problem because it took this long for us to recognize the problem to which you were referring. We mistakenly believed you were speaking about a problem with a sample, not core functionality. Regardless of whether that is a language-barrier related miscomunication, a fault in your explanation, or a fault in our undersating of that explanation, that is why it took this long.

We make every effort to offer prompt and precise support via this forum. As soon as we recognized this particular issue as a core problem, it was diagnosed and fixed ("within 30 seconds", in Trent's words.)

Time is precious for both you and for us, so I will not waste either of our time by continuing the argument any further than this: the problem has been recognized and resolved. It will be posted in the next release. We appreciate your continued business and, regardless of where the fault lies in the delay for this issue, regret that it took so long to resolve.