xsharp.eu

We have successfully converted our mailreader to X#. We do have one issue, which was already the case in the Vulcan program, but maybe someone can comment on it. The program reads the mail every (x) seconds (which can be set). It stores the mails in a DBF and separately stores an eml. file; the VO program only needs to refresh the (b)browser to show the latest changes.

To work, the X# program users a timer, like this:

SELF:oReadTimer := DispatcherTimer{}
SELF:oReadTimer:Tick += System.EventHandler{SELF, @TimerTick()}
SELF:oReadTimer:Interval := TimeSpan{0, 0, INT(SELF:iTimeBetween)}
SELF:oReadTimer:Start()

When we run the program on a Server 2012, it will soon show as "Not responding" in the Task Manager and it won't react on keyboard input either. The same program does not have that problem on Windows 10 systems for example.

What can cause this difference?

I was thinking about moving the read process to Asycn tasks but I am not sure if this will work in Vulcan dialect X# - does Asycn work there or does it need to be Core X# for it?

Dick

Hi Dick,

AFAIK the server is configured to perform background tasks with a higher priority that foreground tasks - and on client operating systems it is the other way.

If the task you are spawing does not use the Vulcan runtime or the DBFCDX driver, you can use it. But unfortunately the Vulcan runtime is noth threadsafe, nor it it the DBFCDX driver.

Wolfgang

Hi Dick,

Yes, everything that works in Core dialect should be working in vulcan dialect as well and in all other dialects. Regarding thread safety, as Wolfgang says the dbf RDDs implementation of the vulcan runtime is indeed not thread safe, but if you are careful not to use multiple .dbf files from different threads, you should not have trouble using them.

Chris

Hello Wolfgang,

If I understand you correctly, Async is not going to work - we use the Vulcan runtime and we write the data in a DBF.

Is there any other way to prevent the "Not responding" status on the server?

I may have found one here but currently I can't check (local problem with the concerning) server. It's reported here https://theorypc.ca/2016/07/22/citrix-x ... artifacts/ where it says I have to set HKCUControl PanelDesktop, key HungAppTimeout to 20000 or so (a larger time out).

If there are other ideas, in case this doesn't work, these are welcome. If it works I'll report back as soon as I can test.

Dick