Problem with window creation at Runtime

[TrevorLE]

Hi Guys

Looking forward to downloading the new version of X# once it is ready, so that we can complete our upgrade testing and finally migrate fully across to X# in the near future !

In the meantime I have an odd issue that I am hoping you can assist with - as follows
- we have a reporting program that we use for customer reports, that has a DataWindow for each report that is full of the report options for the user to select
- we allow them to select the report options and save to a database and then at night we run a program that goes through that database and runs the report program each time for each report set to run. When that runs it
- runs from a scheduling service on a server - so runs in background service / non gui mode
- loads the report program which creates the shellwindow and doesn't show it
- creates an instance of the report settings window (Datawindow) that is being run and doesn't show the window -using a CreateInstance(symWindow, SELF)
- then it populates the controls on the window object and then runs the method that generates the report that gets auto saved to PDF and emailed to the recipient, destroys the window object and then closes and moves on to the next one

All of this works and to date we have been running these reports one after another in a single batch with no problems.
Some of our other nightly processes that don't involve window object creation, we have a routine that uses a Spawn command to run multiple simultaneously - which works well and we need to implement that setup to this automatic reporting process as it is taking too long for some large clients

My Issue is that if I set multiple reports running at the same time from a program run as a service, I get errors like the example error message listed below, which is erroring on the CreateInstance call with a "Dialog creation from resource failed" error.

I put a TRY/CATCH in place and made the program re-try up to 20 times on the createinstance with a random sleep interval between 100 and 1000 milisecs in case it the issue was that the separate processes were trying to create windows at the same time - but that had no effect and it still errored out every time for the 20 retries.

The really odd thing is that if I start the same program manually from a command prompt - which is the program that then launches multiple copies of the report program simultaneously - it works perfectly. I have checked that the scheduling program that starts it automatically is setup to have the same login credentials that I am using when running it manually.

So as far as I can see, the only real difference here is that a task scheduler service is starting the processes manually versus me starting them manually from the command prompt - with one failing and the other not failing and not really sure why this would be the case.

Also note that not every report fails - some are going through so I am thinking it is happening when multiple window objects are trying to be created at once - even though that is happening from separate spawned processes.

So just wondering if anyone has any ideas, has seen this sort of thing before or any ideas on how to trouble shoot or code around the issue as I can trap the error when the CreateInstance fails, but don't seem to be able to code around it as per above.

Thanks is advance
Trevor

// ---------------- Error Message Example -----------
Error Code: 13 [No exported method]
Subsystem: BASE
Description: No exported method
Function: CREATEINSTANCE
Argument(s):
1: VulcanApp (VulcanApp)
Call Stack:
at VulcanRTFuncs.Functions.CreateInstance(__Usual[] $args)
at VulcanApp.Start(__Usual[] $args) in C:VisualStudioProjectsOptions ReportsOptions_Reports_11Start.prg:line 1706

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> Vulcan.Error:
Vulcan.NET Runtime Error

Error Code: 13 [No exported method]
Subsystem: BASE
Description: No exported method
Function: CREATEINSTANCE
Argument(s):
1: Vulcan.VO.__FormFrame (Vulcan.VO.__FormFrame)
2: Vulcan.VO.ResourceID (Vulcan.VO.ResourceID)
Call Stack:
at VulcanRTFuncs.Functions.CreateInstance(__Usual[] $args)
at Vulcan.VO.__FormFrame..ctor(__Usual[] $args)
at Vulcan.VO.DataWindow..ctor(__Usual[] $args)
at OurDataWindow..ctor(__Usual[] $args) in C:VisualStudioProjectsOptions ReportsOptions_Reports_11ClassesMiscClasses.prg:line 1269
at RepILst..ctor(__Usual[] $args) in C:VisualStudioProjectsOptions ReportsOptions_Reports_11RepILstInventoryRepILst.prg:line 10325

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> Vulcan.VO.WCError:
Vulcan.NET Runtime Error

Error Code: 0 [Unknown error]
Subsystem: GUI Classes
Description: Dialog creation from resource failed
Function: DIALOGWINDOW:INIT
Call Stack:
at Vulcan.Error.Throw(__Usual[] $args)
at Vulcan.VO.DialogWindow..ctor(__Usual[] $args)
at Vulcan.VO.ModelessDialog..ctor(__Usual[] $args)
at Vulcan.VO.__FormDialogWindow..ctor(__Usual[] $args)

at Vulcan.Error.Throw(__Usual[] $args)
at Vulcan.VO.DialogWindow..ctor(__Usual[] $args)
at Vulcan.VO.ModelessDialog..ctor(__Usual[] $args)
at Vulcan.VO.__FormDialogWindow..ctor(__Usual[] $args)
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at VulcanRTFuncs.Functions.CreateInstance(__Usual[] $args) ---> System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> Vulcan.VO.WCError:
Vulcan.NET Runtime Error

Error Code: 0 [Unknown error]
Subsystem: GUI Classes
Description: Dialog creation from resource failed
Function: DIALOGWINDOW:INIT
Call Stack:
at Vulcan.Error.Throw(__Usual[] $args)
at Vulcan.VO.DialogWindow..ctor(__Usual[] $args)
at Vulcan.VO.ModelessDialog..ctor(__Usual[] $args)
at Vulcan.VO.__FormDialogWindow..ctor(__Usual[] $args)

at Vulcan.Error.Throw(__Usual[] $args)
at Vulcan.VO.DialogWindow..ctor(__Usual[] $args)
at Vulcan.VO.ModelessDialog..ctor(__Usual[] $args)
at Vulcan.VO.__FormDialogWindow..ctor(__Usual[] $args)
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at VulcanRTFuncs.Functions.CreateInstance(__Usual[] $args)
--- End of inner exception stack trace ---
at VulcanRTFuncs.Functions.CreateInstance(__Usual[] $args)
at Vulcan.VO.__FormFrame..ctor(__Usual[] $args)
at Vulcan.VO.DataWindow..ctor(__Usual[] $args)
at OurDataWindow..ctor(__Usual[] $args) in C:VisualStudioProjectsOptions ReportsOptions_Reports_11ClassesMiscClasses.prg:line 1269
at RepILst..ctor(__Usual[] $args) in C:VisualStudioProjectsOptions ReportsOptions_Reports_11RepILstInventoryRepILst.prg:line 10325
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object[] arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
at VulcanRTFuncs.Functions.CreateInstance(__Usual[] $args)

[robert]

Trevor,
I am not sure if this is what you want to hear, but why on earth do you need to create an invisible window to run these reports.
I think your basic design is wrong here. There should be a non visual component that saves and restores report settings and controls the report. The Window should be just used to edit these settings and call the code that starts the report inside the other component and should have no other purpose.
By separating these tasks you can also call the report "controller" without UI and you will never see this kind of problems.
That will also make it much easier to migrate to a different UI in the future (like Windows Forms or WPF) without having to worry about breaking the code that runs the report.

That having said, the error that you are seeing is a known error in VO as well. The VO GUI Classes are creating a window from a native resource linked into the EXE/DLL. It loads the resource and then calls the Win32 api function CreateDialogParam() to create the window handle.
The MSDN Help suggests to call the Win32 api function GetLastError() to retrieve the error code. I don't think the GUI Classes do this. Maybe you should add a call to GetLastError() to the code that handles your errors. It could reveal the cause .
If you google you will find many references to problems with CreateDialogParam.
I would not be surprised that creating the window without UI is the cause of the problem.

Robert

[TrevorLE]

Robert

thanks for the info. It is like that because we have around 100 report windows and the Automated reporting was created a long time after the report windows were created - so this was the easiest way to implement the automated setup into the structure that we already had.

I will take your comments under advisement, but there would be a massive amount of work to convert it to that type of setup - which I totally understand - but dealing with legacy stuff here !

What still confuses me is that if I run the exact same process from a command prompt, it works perfectly - it is only when it is initiated from a background service that there is an issue.

thanks for the quick response!

cheers
Trevor

[wriedmann]

Hi Trevor,

a background service has no GUI and no access to one, so such errors are likely to success.

Try to launch your process from a planned task, maybe that runs better.

I had issues with COM SxS functionality in services - the same functionality works perfectly in planned tasks.

Wolfgang

[lumberjack]

Hi Trevor,

As indicated by others, using windows to store parameters will always be an issue with services.
To get you on the right track, look at the class

System.Collections.Specialized.NameValueCollection

It is basically a class that stores <Key>, <Vallue> pairs as strings and can also store STRING[] in the value.

I have sub-classed it based on an idea that I got from Bert Dingeman's website. It fulfill all my needs for storing configuration information, to such and extent that I even use it as Bert also did as interface between database tables and UI.

I have send Chris a copy of it about a year ago, so not sure if he can comment on its usage, It can be uploaded to the downloads section of the website if there would be enough interest. It might not be such a big job to convert from the Windows interface.

Regards,
Johan Nel

[TrevorLE]

Thanks for the suggestion Wolfgang

I haven't found any other easy solution to this other than recoding the design which would be a large task - would you mind elaborating on what you mean by a "planned task"as I haven't used them before and a Google search didn't enlighten me, but it might be worth a try?

thanks in advance
Trevor

[wriedmann]

Hi Trevor,

if I understand correctly, your procedure is running as Windows service.

You could change it to be a standalone program and start it from the Windows Task Scheduler:
https://msdn.microsoft.com/de-de/library/windows/desktop/aa446802(v=vs.85).aspx

This way I have solved my problems with COM modules (I was not able to use SxS COM modules, written in X#, from a Windows service written in VO). With a planned task these modules work very well.

Wolfgang

[TrevorLE]

Ah - Ok thanks - but I have already tried running that from task scheduler as well as a third party scheduler with the same results.

thanks for the info !

cheers
Trevor