dynamic-new is not working on webclient...

Sharad,

What error message are you getting? Perhaps your propath on webclient is not correct.

This sounds like a variation of an issue that we are working on within development. Currently there is a bug logged indicating that static class members do not work in a WebClient configuration. This is because the runtime engine for static utilizes functionality that is part of the compiler. However, the compiler is not part of the WebClient executable. I believe that DYNAMIC-NEW has the same internal issue and therefore will not function properly. The developer working on this issue, will address both issues.

I know, that you are not able to make promises before the issues has been fixed by development, but is that something that you'd make available in SP1 or do we need to wait for 10.2B?

I know, that you are not able to make promises before

the issues has been fixed by development, but is that

something that you'd make available in SP1 or do we

need to wait for 10.2B?

I don't want to talk for Evan and haven't looked at this specific issue but it sounds like a bug rather then an enhancement and so assuming the fix makes it in time and isn't seen as something that could break peoples applications or is "dangerous" (please don't ask me to define "dangerous" in this context) it would go into the Service Pack. It would probably be wise to log a call on the Dynamic New not working to have it officially in the system. Mention that Evan said it is probably related to the other issue.

HTH

Hmmm, I read it as something other than a bug. Rather it sounded like these features relied on availability of the compiler and that was missing in WebClient.

Hmmm, I read it as something other than a bug.

Rather it sounded like these features relied on

availability of the compiler and that was missing in

WebClient.

You could be right but I thought it was more of a case that its valid to have these things as dynamic and run as a client process. The biggest difference between full client and webclient is no compiler and no database connections. It seems like they just have to work out how to do that either with no compiler or with minimum compiler functionality (note: I have no insite into the fix being looked at, just speculating). So I would call it a bug but others might not.

I read all comments. thanks.

Only workaround I could find workable was using factory method. Though I am not sure how technically good it is. Further looking for any better solution.

Nothing is really wrong with a class factory - except that it's not that flexible as the DYNAMIC-NEW. So that might be your workaround.

But with Matt, Phil and Evan you have 3 technical people from Progress around the globe listening... How about sharing some details about the error you have? In parallel you should log a but with tech support.

Thomas and I also have a bit of experience with Progress - so we might help as well.

Well from a customer point of view: If it's not documented (in the language docu) that DYNAMIC-NEW and the access to static members is not supposed to work - I call it a bug.

It does not make a too big difference from my point of view if it's bad code causing the issue or wrong packaging of libraries in the webclient.

Sharad, you should indeed log a bug for this limitation.

While I recognize that it is not as flexible, in some ways I would prefer a factory solution since it is more traceable. All this dynamic stuff makes it very hard to build or follow a call graph.

While I recognize that it is not as flexible, in some

ways I would prefer a factory solution since it is

more traceable. All this dynamic stuff makes it very

hard to build or follow a call graph.

I prefer to use something that combines both.

Now you have the benefits of both the dynamic invocation and the pattern (and traceability, modularisation etc).

-- peter

You only have traceability if you have a human reading the coding and following where the name comes from and is used. If you try to automate the call graph then it becomes untraceable without providing "hints" to the tracing tool, e.g., John Green's Analyst product. Hopeless trying to get it from XREF.

You only have traceability if you have a human

reading the coding and following where the name comes

from and is used. If you try to automate the call

graph then it becomes untraceable without providing

"hints" to the tracing tool, e.g., John Green's

Analyst product. Hopeless trying to get it from XREF.

I'm not sure I understand how using DYNAMIC-NEW within a Factory is any different to using NEW within a Factory, from the perspective of traceability. In both cases, there's some string representation of a class (ie a name) to invoke being passed as an argument.

-- peter

I am totally aligned with Philip's posting from yesterday at 5:33 PM. I have updated the bug that we already have in the system, noting that the developer should evaluate whether or not this issue can be addressed in the next service pack. Additionally, I noted that we need to verify that both static and DYNAMIC-NEW function properly in a Web Client configuration.

However, please log this issue with Technical Support, so that your specific issue can be properly recorded in the system.

You don't see any difference between

NEW object-type-name

and

DYNAMIC-NEW expression

where expression can be a parameter from outside the class?

Tried doing an XREF on both?

There is definitively a difference. My preference is a class factory when I / my team has influence on the class being instantiated.

In my framework, I enable the user (well the developer of an organization using it) to name different dialogue classes (visual designer generated form) in a configuration file. So if you want you custom login screen design or message box design, simply create it against an Interface declaration from me. No logic, just UI. That combined with the Infragistics AppStylist gives full freedom of the UI...

The code looks like this:

DEFINE VARIABLE oLoginDialog AS ....ILoginDialogForm NO-UNDO.

cLoginDialogForm = getSessionProperty ("LoginDialogForm").

IF cLoginDialogForm > "" THEN

oLoginDialog = DYNAMIC-NEW (cLoginDialogForm) () .

ELSE

oLoginDialog = NEW LoginDialogForm () . /* that is my reference class */

That combines NEW and DYNAMIC-NEW. Joanju analyst should at least be able to trace the static NEW.

You don't see any difference between

NEW object-type-name

and

DYNAMIC-NEW expression

where expression can be a parameter from outside the

class?

I wasn't thinking of a call graph (which was admittedly your point). I was thinking more in terms of the ability to debug the invocation.

-- peter

The code looks like this:

DEFINE VARIABLE oLoginDialog AS ....ILoginDialogForm

NO-UNDO.

cLoginDialogForm = getSessionProperty

("LoginDialogForm").

IF cLoginDialogForm > "" THEN

oLoginDialog = DYNAMIC-NEW (cLoginDialogForm) ()

.

LSE

oLoginDialog = NEW LoginDialogForm () . /* that

is my reference class */

I think my preference would be

I would also think about adding the GetSessionProperty() call to the factory, and have no arguments, so that the factory does all the work. After all, does the caller need to know how the decision was made about which object was created?

That combines NEW and DYNAMIC-NEW. Joanju analyst

should at least be able to trace the static NEW.

True. And if you encapsulate the decision in the Factory, you need never worry about whether a caller might have made a mistake - you know that the same, correct dialog is always used.

-- peter

Well, yes, it was my point ... use of dynamic calls makes it very difficult to trace impacts and identify where things are used. Analyst does an amazing job at resolving these links, especially if given some hints, but I tend to think that one should not make the job any harder than it has to be. To be sure, there are some places where there is just no other reasonable approach, but I think that people get hooked on how cool this dynamic stuff is and use it in places where it really isn't necessary.

It is encapsulated... But using procedural code. The login screen and message screen and all the other in Dynamics have a procedural legacy...

To be sure,

there are some places where there is just no other

reasonable approach, but I think that people get

hooked on how cool this dynamic stuff is and use it

in places where it really isn't necessary.

Amen to that. The right tool for the right job, as my father always used to say*.

-- peter

• usually right after I'd used a can opener to open a bag of chips

Well I see the biggest beauty of OO coding in strong typing. Let the compiler do as many checks as possible.

DYNAMIC-NEW against an Interface should be the only exception. And so I'm glad, that we don't have dynamic method calls and property set/get in the ABL. I hope it stays that way!

I'm glad that he also told you how to open a bottle of beer properly... At least in Europe you need tools for that as well.