4D V11 Application Process - hogging massive processing
steve simpson (7/20/08 9:03AM)
4D, Inc. (7/21/08 11:45AM)
Chip Scheide (7/21/08 5:07PM)
steve simpson (7/21/08 6:39PM)
David Dancy (7/22/08 9:03AM)
steve simpson (7/20/08 9:03 AM)
time
<8c8b66580807200603h35944302s9c72ee99858ee1b4@...
On Sun, Jul 20, 2008 at 3:00 AM, Tony Ringsmuth wrote:
When I go into the design environment of 4D v11.2 on my dual-core
MacIntel
machine, the "Application process" becomes a massive processor hog: My
Activity Monitor shows 4D at a near constant 96+% of usage. It make
the
whole machine sluggish, and 4D very sluggish.
The "Application process" behaves well UNTIL I go to debug mode, and
click
Edit or Abort & Edit. At that point, it begins chewing up all
available
processing power until I restart 4D.
Anyone else seeing this?
No. I'm not seeing this behaviour in any ver of v11, on a dual core
with
WinXP. In fact, it seems to have a lower base line activity level than
previous versions. And going to design/debug/edit doesn't add to it.
You are
positive you haven't started some hidden process during startup that
continues to run longer than expected?
--
Steve Simpson
813-264-2706 office
813-478-7381 cell
4D, Inc. (7/21/08 11:45 AM)
time
Hi Tony,
Just a guess...
Tony Ringsmuth wrote:
I have found some new info: If I force my application process to get
out of
my main event loop, and "finish" (come to the end of any custom code vs
staying in the home screen or main event loop), then the application
process
finally comes back into bounds of normal processing.
You're probably doing "DELAY PROCESS"? Is the delay actually working?
Or has it spun off into a tight loop?
This is just a hunch, because it used to be you could not delay the
User/Custom Menu process. You're supposed to be able to delay the
Application Process in 11, but perhaps you're triggering something by
going into Design Mode.
Kind regards,
Josh Fletcher
--
Josh Fletcher
Technical Services Team Member
4D, Inc.
4D Server v11 SQL has arrived!
Buy it NOW at <http://store.4ddepot.com/>
Chip Scheide (7/21/08 5:07 PM)
time: More Info
This has fueled the Following Notation on the wall in my office:
We fix our coding problem - free
We fix another developers coding problem - Standard Rate
We fix *Your* coding problem - Double Rate
We Fix *Your* coding problem, and you try to help/watch/kibitz -
Triple
Rate
: )
On Mon, 21 Jul 2008 13:33:36 -0600, Dennis Little wrote:
Yeah, it's really sweet. Our customers love going in and writing their
own features instead of calling us. I've been able to lay off over half
of my development staff!
steve simpson (7/21/08 6:39 PM)
<8c8b66580807211539j23001971oeb9b490279d295a1@...
On Mon, Jul 21, 2008 at 5:35 PM, Doug Cottrill wrote:
My question is, what are
the advantages
of doing this vs letting the startup method end and handling actions
with
menus
as the user interacts with the program? I generally start a separate
process for
a splash screen with a bunch of buttons on it, but it is not in a
loop, it just sits there
waiting for button clicks. Is the "main event loop" a misnomer, or
is it really a loop
that waits for an action from a screen that closes and re-opens after
every button
click? Just curious as to the reasoning here.
I would call your event handler splash screen your version of a "main
event
loop". If it is a process you started that is sitting there handling
most of
the sub routines which may then have their own screens and menus, but
which
eventually end to return the user to your central event handler "splash
screen", then you are doing basically what many do, and I use the term
"main
loop" for that. Probably just semantics and the specific term may well
be
out of date. But if you are building shrink wrapped database products,
you
will have a pretty basic plain jane 4D-branded application if you
don't do
something of your own to control the whole environment and morph it
into
your specific product's branded world. If you are in a company
environment
only and everyone refers to it as "4D", and expects to see the naked
user
environment, then you probably don't have need of the control a startup
event handler splash screen sustained by a "main event loop" gives
you. You
can just change the menus as needed and present the basic 4D world as
is. I
would venture that most "application shells" out there rely on some
form or
another of a basic startup "main event handler loop" (whether or not it
actually "loops").
--
Steve Simpson
813-264-2706 office
813-478-7381 cell
David Dancy (7/22/08 9:03 AM)
time
<650f557e0807211603j2a22fb8cxb5cf52b09800c292@...
Tony
If you're using the bang-up-to-date version of 11.2, check out the
extension to the DIALOG command (see the new addendum). It will allow
you to open a window (e.g. your "splash" window that you open on
startup) but _it returns execution control straight away to the same
process_. So you have
`... complicated on startup code goes here
DIALOG("MySplashScreen") `project form, not table form, but it doesn't
matter
`... control returns to this method as soon as the dialog displays,
and doesn't require a new process.
`... this means that On Startup can now complete and you can still
have a splash screen open
You may find you don't need a main even loop any more.
HTH
David
Reply to this message
Summary created 7/21/08 at 7:26PM by Intellex Corporation
Comments welcome at: feedback@intellexcorp.com