Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

.Compose Question

Status
Not open for further replies.

iwells

Programmer
Oct 2, 2012
284
CA
Hi,

Fairly inexperienced with the COMAPI and had a question about .compose method of a view. My questions are:

1) What is the purpose of this? I think the purpose of .compose followed by Array(...) is different than dblink.openview in that it "automatically" joins the views you specificy in the array and provide extra data in the view other than the base view specified in the dblink.openview? I equate this to using joins (array) rather than a simple select from (.openview) ... is my assumption correct?

2) can you "nest" arrayed views in other .compose method calls? for example, assuming I'm right in part 1 and I vGLPOST.compose (vGLPOSTO) and then use vGLPOST inside a later array does it also include the information joined from the previous compose?

If I'm totally wrong on this can someone give me a brief tutorial?

Thanks,
Ian
 
Compose = link tables
I don't understand question 2 - it makes no sense to me. I'm going with no as an answer.

Sage 300 Certified Consultant
 
1. They're not views like SQL views, they're a key part of the business logic layer. Use what you see when you record macros, and don't add or subtract anything.
2. No.
 
Tuba, the thing is lots of times when I open a window to record a macro there are several .compose statements with arrays, but if I look in the sage application object models I can see that the data I need isn't in the views that are being linked in the .compose. I'm trying to cut out extra code I don't need.
 
I have 17 years of experience coding to Accpac views, and I've learned that unused views don't hurt a thing, and you never know when you'll need them later in the project.
 
I tend to agree with you, but I just chopped a procedure down from 200+ lines to 20 lines and there are more like this in the macros I'm editing, so it makes it very difficult to understand what's happening with some of the cluttered code.
 
I'm with Jay, Compose are the least of your problem.

If you want to unclutter the code then get rid of all the Temp= crap etc.

I clean up code by moving all the Dim lines to the top, move the OpenViews together followed by the Compose lines.


Sage 300 Certified Consultant
 
Ditto with ettienne. And get rid of the xxxfields objects, use xxx.Fields instead.
 
I definitely reorder the Dim statements, openviews, set statements and several other things, but I also favour removing unnecessary lines of code to make it easier to read and understand what's being used and what isn't and especially if someone else who isn't familiar with the macro has to come behind you and read it.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top