[Date Prev][Date Next] [Thread Prev][Thread Next]
[Date Index] [Thread Index] [New search]

RE: F_ApiGetNamedObject and FO_RefPage

Your suggestions helped alot.  
 
The reference pages are quite different.  But the differences seem to be
induced further upstream.  
 
Programatically, I am opening a text file named machine-data.ent that
contains some entity definitions.  Since I am doing this in the background,
get the default property values and change some of the values.  Here's the
code for that:

propvalsParam = F_ApiGetOpenDefaultParams();
 iIndex = F_ApiGetPropIndex(&propvalsParam, FS_AlertUserAboutFailure);
 propvalsParam.val[iIndex].propVal.u.ival = FALSE;
 iIndex = F_ApiGetPropIndex(&propvalsParam, FS_MakeVisible);
 propvalsParam.val[iIndex].propVal.u.ival = FALSE;
 iIndex = F_ApiGetPropIndex(&propvalsParam, FS_ShowBrowser);
 propvalsParam.val[iIndex].propVal.u.ival = FALSE;
 iIndex = F_ApiGetPropIndex(&propvalsParam, FS_UseAutoSaveFile);
 propvalsParam.val[iIndex].propVal.u.ival = FALSE;
 iIndex = F_ApiGetPropIndex(&propvalsParam, FS_UseRecoverFile);
 propvalsParam.val[iIndex].propVal.u.ival = FALSE;
 iIndex = F_ApiGetPropIndex(&propvalsParam, FS_RefFileNotFound);
 propvalsParam.val[iIndex].propVal.u.ival = FV_AllowAllRefFilesUnFindable;
 iIndex = F_ApiGetPropIndex(&propvalsParam, FS_StructuredOpenApplication);
 propvalsParam.val[iIndex].propVal.u.sval = strCurrDocAppl;
 
In both cases, the F_ApiOpen succeeds but when I get the name associated
with the returned ID, FM 5.5.6 gives me machine-data.fm and FM 7.0 give me
machine-date.ent.  That turns out to be a big difference because the
machine-data.fm in 5.5.6 has all the Reference Pages that one would expect,
including EDD_HTML, Reference, TOC, and Entity Declarations.  The reference
pages in machine-data.ent are Reference, HTML, HTML and Headings.  So,
obviously my call to F_ApiGetNamedObject on the Entity Declarations page
will come up empty.
 
It turns out that those index fetches I show above return different indexes
for the property values in the arguments.  That in itself shouldn't be an
issue, but it does mean that Adobe changed something in default setting
structure.  However, I believe that the end results are consistant with the
two FDK's.  The differences seem to follow the Framemaker application
versions.  I verified this by running the plug-in, compiled with FDK5.5.6 in
the FM 7.0 application.  The file name associated with the opened entity
file is machine-data.ent for both plug-ins running in FM7.0.  
 
Chuck  

-----Original Message-----
From: Sue 
Sent: Thursday, May 22, 2003 11:30
To: 'Vorndran, Charles P'
Subject: RE: F_ApiGetNamedObject and FO_RefPage



No I don't think it means that Entity Declarations is not 'valid' I think it
simply means that it isn't there - you are positive that the file that
g_MachineDataId is referencing has a Reference Page called Entity
Declarations? AND that there are no spelling mistakes?? (could be that in
FM7 it is called something slightly different)

This may be obvious but what the Command F_ApiGetNamedObject is doing (or
trying to do) is to get the id of the Reference Page called "Entity
Declarations" in your document with the g_MachineDataId. So if it is
returning -20 I would guess that either the spelling is incorrect or else
you are referencing an file (through your g_MachineDataId) that does not
have that Reference Page.

A couple of quick tests to make sure you have all the right ID's would be to
get the FP_Name value of g_MachineDataId to see if you have the right file.
If so then get the FP_FirstRefPageInDoc of g_MachineDataId and then loop
through all the reference pages checking out their names to see if you can
see Entity Declarations.

Hope this helps 

Sue 



-----Original Message----- 
From: Vorndran, Charles P [ mailto:Charles.Vorndran@usa.xerox.com
<mailto:Charles.Vorndran@usa.xerox.com> ] 
Sent: Thursday, May 22, 2003 11:09 AM 
To: 'framers@omsys.com' 
Subject: RE: F_ApiGetNamedObject and FO_RefPage 


Thanks to Sue, in Ottawa, for reminding me to look at FA_errno and for the 
Reference Page information below.  
  
I reset FA_errno to zero just prior to the F_ApiGetNamedObject call.  After 
the call, FA_errno took on the value of -20 (FA_NameNotFound).  The comment 
in fapidef.h for this error is /* Can't find object with requested name */. 
Does that mean that the 'name' argument value of "Entity Declarations" is 
invalid in FM7.0?  (In 5.5.6, FA_errno was 0 and an ID of 117710856 was 
returned.)  I viewed the reference page and there is an empty Entity 
Declarations table, as was the case in FM+SGML 5.5.6.  So it looks like I do

have a reference page, but F_ApiGetNamedObject can't find it.  I tried 
casting the quoted string to a StringT, but that didn't change the outcome. 
  
Any thoughts? 
  
Chuck 

-----Original Message----- 
From: Sue 
Sent: Wednesday, May 21, 2003 16:53 
To: 'Vorndran, Charles P' 
Subject: RE: F_ApiGetNamedObject and FO_RefPage 



Entity Declaration is the name of a Reference Page - it has nothing to do 
with the sdk. When you import a file from xml for instance it creates a 
Reference Page called Entity Declarations which it uses to map tables, 
paragraphs etc. If you don't have this reference page in your file then the 
F_ApiGetNamedObject command will return 0 - not found. It is not an error, 
if you want to see if there is an error in the code check the value of 
FA_errno. 

Hope this helps 

Sue 
-----Original Message----- 
From: Vorndran, Charles P [ mailto:Charles.Vorndran@usa.xerox.com
<mailto:Charles.Vorndran@usa.xerox.com>  
< mailto:Charles.Vorndran@usa.xerox.com
<mailto:Charles.Vorndran@usa.xerox.com> > ] 
Sent: Wednesday, May 21, 2003 4:41 PM 
To: '<framers@omsys.com>' 
Subject: F_ApiGetNamedObject and FO_RefPage 


Here's a Client API question for the hard-core developer types: 

I'm trying to understand the behavior difference in one of our custom 
plugins that I inherited for maintenance.  The difference is the result of 
changing platforms from FM+SGML 5.5.6 to FM 7.0. Here's the situation. 
There's an API client call to F_ApiGetNamedObject as follows: 
idEntDecl = F_ApiGetNamedObject(g_MachineDataId, FO_RefPage, "Entity 
Declarations"); 
where g_MachineDataId is a valid ID returned by M_CBHiddenOpen(strFileName) 
for a valid entity definition file. 

In FM+SGML 5.5.6 the value of idEntDecl is a valid FM internal ID, allowing 
the plug-in that it lives in to work just fine.  In FM 7.0, however the 
value of idEntDecl is zero.  This causes the plug-in to fail in 7.0 on the 
very actions that were so very successful in 5.5.6. 

So, I'm looking for a little insight.  How do I know that "Entity 
Declarations" is a valid name parameter for an FO_RefPage object? 
Unfortunately, the author of this code is nowhere to be contacted so I can't


ask him how he found it.  And the FDK documentation falls a bit short in 
that area. 

Also, are there any hints as to why there would be a behavior difference 
between 5.5.6 and 7.0?  It doesn't seem be the FDK because I used the FDK7.0


to compile a plug-in that worked fine in the FM+SGML 5.5.6 environment.  But


neither the FDK 5.5.6 built plug-in or the FDK 7.0 built plug-in works in 
the FM7.0 environment. 

Thanks for taking the time to read this. 

Chuck Vorndran 
Software Development Engineer 
Xerox Corporation 

Chuck Vorndran 
Software Development Engineer 
Xerox Corporation 
  Xerox Global Services / eServices 
extension: 18717 
intelnet: 8*221.8717 
outside: +1 585.231.8717 
  

** To unsubscribe, send a message to majordomo@omsys.com ** 
** with "unsubscribe framers" (no quotes) in the body.   ** 

This message may contain privileged and/or confidential information.  If you

have received this e-mail in error or are not the intended recipient, you 
may not use, copy, disseminate or distribute it; do not open any 
attachments, delete it immediately from your system and notify the sender 
promptly by e-mail that you have done so.  Thank you. 


** To unsubscribe, send a message to majordomo@omsys.com ** 
** with "unsubscribe framers" (no quotes) in the body.   ** 

This message may contain privileged and/or confidential information.  If you
have received this e-mail in error or are not the intended recipient, you
may not use, copy, disseminate or distribute it; do not open any
attachments, delete it immediately from your system and notify the sender
promptly by e-mail that you have done so.  Thank you.


** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **