AppBuilder uib_is_running

A bit of deja-vu here - haven't you already asked this ?

Didn't you see Edsels reply in this version of your post?

http://www.psdn.com/library/thread.jspa?threadID=15081&tstart=0

I asked, but got Java errors in response.

So I asked again.

And again.

Each time I got the same response. I think the third try may qualify me according to widely accepted definitions of insanity.

Has anyone found a solution for this yet?

mikefe wrote:
Didn't you see Edsels reply in this version of your post?
http://www.psdn.com/library/thread.jspa?threadID=15081&tstart=0

That link is unfortunately broken.

-peter

That link is unfortunately broken.
-peter

Well, all links to the "good old psdn" are boken. I'm pretty sure, that no-one of us would ever deliver such a crappy conversion to one of our customers. I still have the hope, that someday somebody will "fix" this.

I'm not sure if that's the link to the discussion I referred to, but this looks promising as well: http://communities.progress.com/pcom/message/35666#35666

In the meantime I have fixed this by checking the following in the constructor of user controls:

In our standards* it is forbidden to create directories or sources that contain 'eclipse' in the name. 
* Effective as of today 

Now you only have to convince Progress not to change anything in the folder structure of their product or the name of the launcher program as that would break your test. Not very future-proof, I'd say.

Are you seeking for a solution for AppBuilder .w files or GUI for .NET cls files?

Of course.

Although this simple solution may well work without a glitch for many years to come.

For future proofness I am considering putting the line in an include file

We are looking for a solution for GUI .NET .cls files.

rbf schrieb:
We are looking for a solution for GUI .NET .cls files.

Peter Judge gave me this link a while ago: http://dotnetfacts.blogspot.com/2009/01/identifying-run-time-and-design-mode.html

That's what we are using in our UserControls and Components.

"Another issue of the DesignMode property is that it doesn't work inside the constructor of a UserControl or Form!"

That is exactly where I need it now...

I am quite happy with my current workaround and it will probably get more sophisticated in the future.

Peter Judge gave me this link a while ago: http://dotnetfacts.blogspot.com/2009/01/identifying-run-time-and-design-mode.html
That's what we are using in our UserControls and Components.

Dammit. You beat me to myself. Or something like that.

Here's some ABL code I use for this:

using System.Windows.Forms.*.
using System.ComponentModel.*.
/* Simply an inverse of the IsInDesignMode() method */
method static protected logical IsInRuntimeMode():
  return not MyForm:IsInDesignMode().
end method.
       
method static protected logical IsInDesignMode():
  return EnumHelper:AreEqual(LicenseManager:UsageMode, LicenseUsageMode:Designtime).
end method.

Note that this only works for stuff being run by the design canvas (ie as the WYSIWYG editor is being drawn). If you run anything from OEA, it's typically* a separate AVM and thus no longer qualifies as design mode by the criteria above.

Trying to distinguish between "run properly by my app launcher" and "run from design surface" is a little more painful.

method protected logical InvokedByDesigner():
 return (not MyForm:StartedProperly and MyForm:IsInRuntimeMode()).
end method.

Note that this depends on the "run properly" process setting MyForm:StartedProperly to True when it runs. Note further that the use of a static property is safe because the AVM is single-threaded, and so only one form can be invoked at any given moment.

-- peter

* I say typically because I'm not sure of how this works if your launch configs re-use the project AVM.

rbf schrieb:
"Another issue of the DesignMode property is that it doesn't work inside the constructor of a UserControl or Form!"
That is exactly where I need it now...
I am quite happy with my current workaround and it will probably get more sophisticated in the future.

That's why we are using the LicenseManager in the constructor (and saving the result in a property for later use).

Dammit. You beat me to myself. Or something like that. 

This time you beat me.

pjudge wrote:
* I say typically because I'm not sure of how this works if your launch configs re-use the project AVM.

Not to mention sharing AVMs by multiple projects in 10.2B...

Anyway, thanks for the replies, we will investigate them.

-peter