Application sometimes freezes up when returning from form to browse

Something else I thought of is the ini file. Because there is an ini file read when opening the window in order to get the window state and position and at some point a file write back to the ini probably when the window is closed, I also wonder if its a disk read/write issue

Have you tried disabling the ini file window positions so its not using it to get the window position?

I’m not against the use of a logging file of sorts because like using debugview, the last entry written to file or sent to debugview will be around where it hangs, but if its something in the clarion runtime, writing to file which uses the clarion runtime could make it harder to isolate.

@vitesse mentioned using string theory to do the log writing here OutputDebugString directly to file? - #17 by vitesse.

If stringtheory is using windows api’s and not the clarion runtime to read/write to files, this could also work at helping to isolate the clarion runtime instead of using debugview, but if its a windows disk writing issue because there is a lot going on here in a very very short space of time, would writing to disk help instead of sending it to debugview where it sits in memory until saved to disk?

So can you add some logging to the abc classes then to get more info?

Not yet, comes on my list “Things tot try”. I do not all in the same time, because then I still don’t know what worked.

That I work with a log file is simple. The errors are that random that it can go good for a long time and suddenly out of the blue the freezing up happens. I cannot expect from my users that they use DebugView correctly and report problems to me. With the logfile a can check for every user (the log files are in the user directory) if and when an error occurred. And yes I use StringTheory to log the files, that was the outcome of my other post yesterday.

No idea how I can get that working, using StringTheory. But that is the next step, maybe the logging as I havve it now will do (I hope).

Well it will mean including the string theory class from the abc classes, but its easier to just declare the outputdebugstring api in in a module in the class.

Maybe you could derive the class?

I know what you mean which is why I wouldnt rule anything out, including windows playing up. I’ve said before I think these computers are a variation of Herbert Hoover’s New Deal, in other words these computers are a just a scientific psychometric test of sorts and I say this because I’ve got wise to some of the testing they have done to me over the years.

Well I rule out aliens… :nerd_face:

Can you? :grinning: [20 char limit extender]

I have an update on this. It appears to be that when an application freezes up the process hardly takes up more RAM than a well-running precess. But the CPU time is around 27-30% where it normally take 0-7%.

So that means it is probably “busy”. But with what? And why random? It is just a form that closes and returns to the calling browse.

Some more observations:

  1. It appears to happen to some users only (on the same server). But I also noticed that one user who had this problem for a few weeks now seems to have no problem and now another user has the problem for the last two weeks.

  2. When the application freezes up (or is busy) most of the time the form is not closed, but occasionally the browse shines trough the form. It looks like the screen is not completely repainted when closing the form.

Right now I am considering to call the InvalidateRect API when closing the form. Opinions on that?

I’ve used it for fixing the display turds on problem windows. It won’t help your “freezing” though.

“Busy” could mean an endless loop somewhere, either in your control or not.

Endless loop makes sense. But I don’t believe it is caused by my code because it happens too random. Random on which browse/form combination it happens and random when it happens. Or at least it appears to be random to me.

So I am really curious what is causing that endless loop.

Maybe you could try using procmon if it occurs again? Or maybe Spy++ could detect some windows messages?

1 Like

I guess you mean ProcessMonitor from SysInternals? Good suggestion, I will install that now.
Installing Spy++ might be a problem. I will ask our provider tomorrow if he can do that without installing Visual Studio.

I think I got it with WinSdkSetup, but not sure. The file is located here on my machine, but I don’t have Visual Studio installed. “C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\Tools”.

It either came from WinSDKSetup, or VS Code.

OK, I will point our provider to that. I guess they have one of them available.
Meanwhile I tested ProcMon. Takes some time to understand this tool. I must RTFM :grinning:
But indeed it might give a clue once a process appears to be in a endless loop again.

The 3 things you need to know about procmon:

  1. Set your filter correctly, or you’ll get jillions of useless events.
  2. Under the “Filter” menu, make sure “Drop Filtered Events” is selected, or it will get very sluggish.
  3. Ctrl+E will toggle capturing of events.
3 Likes

Thanks for that direction. I overlooked that one.
Coincidently I had a freeze this evening so I could “practise”. Unfortunate no clue yet, but maybe better next time.