Im exporting a reports from dataset to a execel file,i have a lots of reports so it consuming me a lots of time,so I try to solve this by the background worker cuz I'm working on windows form application,but the new issue come,when begin excuting the report my form is not responding,I'm not able to move the form or click on the stop button(that stop the application).
this is a sample of my code :
#region x Report
PrimaryReportsThreads++;
ADIR_Parameters ADIR_Parms = ConfigManager.GetADIRParameters();
BackgroundWorker ADIR_worker = new BackgroundWorker();
AllThreads.Add(ADIR_worker);
ADIR_worker.DoWork += new DoWorkEventHandler(ADIR_worker_DoWork);
ADIR_worker.RunWorkerCompleted += new RunWorkerCompletedEventHandler(worker_RunWorkerCompleted);
ADIR_worker.RunWorkerAsync(ADIR_Parms);
#endregion
Sounds like COM issue.
Probably you should try using MTA, instead of STA
Helpfull links:
http://msdn.microsoft.com/en-us/library/ms809971.aspx
http://msdn.microsoft.com/en-us/library/system.threading.apartmentstate.aspx
Related
I'm trying to invoke browser control in a Window Form using ChromiumFX framework in the Excel VSTO Addin.
The excel application throws the following alerts and another excel instance gets started.
Sorry, we couldn't find Files\Microsoft.xlsx. Is is possible it was removed, renamed of deleted ?
Sorry, we couldn't find Office\root\Office16\debug.log. Is is possible it was removed, renamed of deleted ?
Although I’m able to load the URL in the Web Browser control but i get the above errors multiple time and every time another instance of excel gets initiated.
I’m invoking the following piece of code after which the alerts start appearing.
var assemblyDir = System.IO.Path.GetDirectoryName(new System.Uri(System.Reflection.Assembly.GetExecutingAssembly().EscapedCodeBase).LocalPath);
Environment.CurrentDirectory = System.IO.Path.Combine(assemblyDir, #".");
if (CfxRuntime.PlatformArch == CfxPlatformArch.x64)
CfxRuntime.LibCefDirPath = #"cef\Release64";
else
CfxRuntime.LibCefDirPath = #"cef\Release";
Chromium.WebBrowser.ChromiumWebBrowser.OnBeforeCfxInitialize += ChromiumWebBrowser_OnBeforeCfxInitialize;
ChromiumWebBrowser.OnBeforeCommandLineProcessing += ChromiumWebBrowser_OnBeforeCommandLineProcessing;
Chromium.WebBrowser.ChromiumWebBrowser.Initialize();
Any suggestions on what i might be doing wrong ? Or what piece of code i’m missing ?
I'm trying to make a game (Universal DX11 application) and at some point I need access to image library to allow user to select avatar. But for some reason call of PickSingleFileAsync on picker rises an exception.
Windows::Storage::Pickers::FileOpenPicker^ openPicker = ref new Windows::Storage::Pickers::FileOpenPicker();
openPicker->SuggestedStartLocation = Windows::Storage::Pickers::PickerLocationId::PicturesLibrary;
openPicker->ViewMode = Windows::Storage::Pickers::PickerViewMode::Thumbnail;
// Filter to include a sample subset of file types.
auto filters = openPicker->FileTypeFilter;
filters->Clear();
filters->Append(".png");
openPicker->PickSingleFileAsync();// same exception with create_task(...);
Seems like the sample works only if I put it into UI thread. How can I use picker from my own thread?
UPD: HRESULT:0x80004005
Ok, I just decided to call dipatcher's RunAsync to execute this code. But I still have no idea why I cannot open picker inside non-UI thread.
I have created a System Tray Application using Windows Forms Template (Visual C++) in Visual Studio 2008. I have used ContextMenuStrip and NotifyIcon. It's a managed code as I have used the form and Drag/Drop.
I want as soon as this System Tray Application starts, it starts polling for any new USB devices (from a specific vendor) connected.
The logic is ready except I don't know "Where to put this while(1) loop?"
It works fine in a console app that I made but now we want it to be integrated to the system tray app.
Here is the code snippet:
int numDevices, n = 0;
while(1)
{
Sleep(5000);
numDevices = usb_find_devices();
if(connectedDevices > numDevices)
{
enumDevices();
connectedDevices++;
}
}
It would really be appreciable if anyone could suggest me some pointers on how to proceed.
Thank you Hans! I added a new "Component Class" with WM_DEVICECHANGE and it is working fine.
Just in case anyone needs this info:
If a function needs to be called as soon as the Windows Forms App starts (Systray app in my case), the respective function can be called after the call to "InitializeComponent()" function. Though it is clearly mentioned "TODO: Add the constructor code here", still a beginner (like me) has inhibitions regarding "Where to put this Function Call??" Hope this helps somebody..
is it possible to execute a crystal report (TCrpe component) from a Delphi non VCL main thread when Output = toWindow?
I execute reports from a background thread, and when Output is toPrinter or toExport, everything is fine.
I know that creating forms in a
Delphi non VCL main thread generally is a
bad idea.
When a Crystal
Report is executed, and Output=toWindow, the component creates the output
window on its own. So I cannot prevent that the window is created by the background thread.
So is there a clean way to
execute the report in a background
thread, and display the result in a
cleanly created form?
Version: Crystal11VCL7
The following code does not work:
procedure TMyThread.Execute;
var
cr: TCrpe;
begin
inherited;
cr:= TCrpe.Create(nil);
cr.ReportName:= 'C:\TestReport.rpt';
cr.Output:= toWindow;
cr.WindowParent:= Form1; //This is the main form
cr.Execute;
end;
It seems like the report will be created and immediately destroyed afterwards.
When I enter a message loop right after cr.Execute (while true do Application.ProcessMessages; - which is obviously a very bad idea), the report window is shown nicely.
Any idea, how to do it right? Or is it simply not possible? Thanks!
I haven't had any experience with Crystal for many years (thank goodness) but in the absence of any other reply I would consider approaching the problem from a different angle.
What I do is let the report form be created in the main thread - because, as you've said, it's not a good idea to do the VCL stuff in the background - but I generate all report /data/ in a background thread. Once the data is loaded then the thread signals the main form (or whatever) via a windows message and the report goes and connects up to the dataset/datasource.
Initially I display a blank label over the client area of the report window with a message saying something like 'Report loading...' then once the message is received it hides the label and attaches the data. Works really well here and keeps the UI responsive.
I have a similar situation to this question.
I have a custom sequential SharePoint workflow, deleoped in Visual Studio 2008. It is associated with an InfoPath form submitted to a form library. It is configured to automatically start when an item is created.
It works sometimes. Sometimes it just fails to start.
Just like the question linked above, I checked in the debugger, and the issue is that the InfoPath fields published as columns in the library are empty when the workflow fires. (I access the fields with workflowProperties.Item["fieldName"].) But there appears to be a race condition, as those fields actually show up in the library view, and if I terminate the failed workflow and restart it manually, it works fine!
After a lot of head-scratching and testing, I've determined that the workflow will start successfully if the user is running any version of IE on Windows XP, but it fails if the same user submits the same form data from a Vista or Windows 7 client machine.
Does anyone have any idea why this is happening?
I have used another solution which will only wait until InfoPath property is available (or max 60 seconds):
public SPWorkflowActivationProperties workflowProperties =
new SPWorkflowActivationProperties();
private void onOrderFormWorkflowActivated_Invoked(object sender, ExternalDataEventArgs e)
{
SPListItem workflowItem;
workflowItem = workflowProperties.List.GetItemById(workflowProperties.ItemId);
int waited = 0;
int maxWait = 60000; // Max wait time in ms
while (workflowItem["fieldName"] == null && (waited < maxWait))
{
System.Threading.Thread.Sleep(1);
waited ++;
workflowItem = workflowProperties.List.GetItemById(workflowProperties.ItemId);
}
// For testing: Write delay time in Workflow History Event
SPWorkflow.CreateHistoryEvent(
workflowProperties.Web,
workflowProperties.WorkflowId,
(int)SPWorkflowHistoryEventType.WorkflowComment,
workflowProperties.OriginatorUser, TimeSpan.Zero,
waited.ToString() + " ms", "Waiting time", "");
}
workflowProperties.Item will never get the InfoPath property in the code above.
workflowProperties.List.GetItemById(workflowProperties.ItemId) will after some delay.
This occurs due to the fact that Vista/7 saves InfoPath forms through WebDAV, however XP uses another protocol (sorry, can't remember at the time). SharePoint catches the "ItemAdded" event before the file is actually uploaded (that is, the item is already created, but file upload is currently in progress).
What you can do for a workaround is to add a dealay activity and wait for 10 seconds as the first thing in your workflow (will actually be longer than ten seconds due to the way workflows are built in SPPS). This way the upload will already have ended when you perform to read the item. To inform the users about what's happening, you can add a "logToHistoryList" activity before the delay.