Google Suggest Box-like behaviour using ExtJS v4 tags

[rtweed]

The Google Suggest Box dynamically looks up matching records every
time you type a character. The more you type, the better the
refinement of the list you get. This kind of thing is ideal for
looking up individual records from big data sets, eg patient lists,
drug lists etc. Someone recently asked me if this was available with
EWD.

It actually has been in the form of the ComboPlus field which has been
discussed in another thread in this group (do a search and you'll find
it).

The EWD/Sencha Touch combo field provides this functionality for
mobile apps. See page 60 in:

http://gradvs1.mgateway.com/download/EWD_Mobile_Tutorial_Part2_857.pdf


However, you can also make the ExtJS v4 ComboBox Field tag work in
this way, which is really cool. I probably should abstract this
functionality, because, at present, you have to write the logic
manually and it's a bit laborious. However it's worth giving it a
try. Let me try to explain how you can make it work. This is a
working example that will do a patient lookup on a VistA system.

So first, here's a patient search popup window fragment:

<ext4:fragment onBeforeRender="initialisePatientList^smartVistADemo">

<ext4:window title="Select Patient" id="selectPatientWindow"
autoShow="true" height="300" width="300">

<ext4:formPanel bodyPadding="10" height="150">

<ext4:comboBox id="patCombo" fieldLabel="Patient Name"
enableKeyEvents="true" name="patientName" value="">

<ext4:listeners>

<ext4:listener keyup="function(txt) {var
nvp='comboId=patCombo&text=' +
txt.getValue();EWD.ajax.getPage({page:'updateCombo',nvp:nvp});}" />

</ext4:listeners>

</ext4:comboBox>

<ext4:submitbutton text="Select" nextPage="setPatient" />

</ext4:formPanel>

</ext4:window>

</ext4:fragment>


The onBeforeRender method for this fragment is as follows. This
initialises the contents of the combo box:

initialisePatientList(sessid)

d clearList^%zewdAPI("patientName",sessid)

d appendToList^%zewdAPI("patientName","Select Name","null",sessid)

QUIT ""



What happens is that every time a keystroke is typed in the combo box
text field, a call is made to fetch the fragment updateCombo.ewd,
sending the text string typed so far. This fragment's logic updates
the drop-down with up to 500 matching records (you can define the
maximum to tune the response time). So here is updateCombo.ewd
fragment that does the work:

<ext4:fragment onBeforeRender="updateCombo^smartVistADemo">

<ext4:js at="top">

EWD.ext4.updateCombo = function(comboId,values) {

var comboStore = Ext.getCmp(comboId).store;

var value;

comboStore.loadData(values, false);

};

var comboId='<?= #comboId ?>';

var values = <?= #values ?>;

EWD.ext4.updateCombo(comboId,values);

</ext4:js>

</ext4:fragment>



and here is its onBeforeRender method:

updateCombo(sessid)

n comma,no,options,prefix

;

s prefix=$$getRequestValue^%zewdAPI("text",sessid)

s comboId=$$getRequestValue^%zewdAPI("comboId",sessid)

d setSessionValue^%zewdAPI("comboId",comboId,sessid)

d deleteFromSession^%zewdAPI("options",sessid)

d comboList(prefix,.options)

d mergeArrayToSession^%zewdAPI(.options,"options",sessid)

s values="["

s no="",comma=""

f s no=$o(options(no)) q:no="" d

. s
values=values_comma_"{name:'"_options(no,"displayText")_"',value:'"_options(no,"value")_"'}"

. s comma=","

s values=values_"]"

d setSessionValue^%zewdAPI("values",values,sessid)

QUIT ""

;

comboList(prefix,options) ;Generates the list of patients for the
combo box

n id,no,name,stop,U

;

s U="^"

s prefix=$$zcvt^%zewdAPI(prefix,"U")

;

;Generate the list of patients in the combo box to match what the
user typed

;

k options

s name=prefix

i prefix'="" s name=$O(^DPT("B",prefix),-1)

s no=1,stop=0

f s name=$o(^DPT("B",name)) quit:name="" d q:stop

. i $e(name,1,$l(prefix))'=prefix s stop=1 q

. s id=""

. f s id=$o(^DPT("B",name,id)) q:id="" d q:stop

. . s no=no+1 i no>500 s stop=1 q

. . s options(no,"displayText")=name

. . s options(no,"value")=no

. . s options(no,"id")=id

QUIT



Give it a try - swap the VistA Patient global lookup loop with an
equivalent one for your own particular data.

You now have Google Suggest-like behaviour!

Rob

[Michael Reach]

Yes!
Thanks,
Michael Reach

> values=values_comma_"{name:'"_options(no,"displayText")_"',value:'"_options (no,"value")_"'}"

[Steve Owen]

Tks Rob, I was looking for that exact bit of functionality in an EWD project
I just started working on!

--
You received this message because you are subscribed to the Google Groups
"Enterprise Web Developer Community" group.
To post to this group, send an email to
enterprise-web-de...@googlegroups.com.
To unsubscribe from this group, send email to
enterprise-web-develope...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/enterprise-web-developer-community?hl=en-GB.

[Michael Reach]

Rod, I tried the functionality in the pdf
http://gradvs1.mgateway.com/download/EWD_Mobile_Tutorial_Part2_857.pdf
(p. 60)
and I'm seeing partial results:
The field itself appears in the form, with the preset value I set.
_And_ the loading code (you called in comboDemoMethod) works as well;
I can see the divs it created in Google Developer (inside div
id="zewdComboPanel"), with the proper values returned. The only thing
that isn't working is that I cannot see them on the page. Developer
even shows where the divs should be, with class div.x-list-item-body,
stacked moving down the page, but I can't see them. Is there a problem
with the class?

I'm not sure how much of the surrounding markup you want to see, but
I'm including it.

<ewd:config isFirstPage="true" cachePage="false" pageTimeout="1200"
prePageScript="getMainMenu^ewdLessonScripts" />

<st:container rootPath="/sencha-1.1/" title="EWD Mobile Tutorial">

<st:images>
<st:image type="tabletStartupScreen" src="/sencha-1.1/examples/
kitchensink/resources/img/tablet_startup.png" />
<st:image type="phoneStartupScreen" src="/sencha-1.1/examples/
kitchensink/resources/img/phone_startup.png" />
<st:image type="icon" src="/sencha-1.1/examples/kitchensink/
resources/img/icon.png" addGloss="true" />
</st:images>
<st:locale dateFormat="d/m/Y" />

<script src="/stdemo2.js" />

<st:content>
<st:panel fullscreen="true" scroll="vertical" >
<st:toolbar dock="top" title="EWD Mobile" >
<st:toolBarButton text="Hide bottom toolbar" id="hideBtn"
handler="EWD.sencha.onHideBtnTapped" />
<st:toolBarButton text="Show bottom toolbar" id="showBtn"
handler="EWD.sencha.onShowBtnTapped" hidden="true" />
<st:toolbarButton type="autoback" id="backBtn" text="Back"
hidden="true" cardPanel="mainCardPanel" />
</st:toolbar>
<st:toolbar dock="bottom" id="bottomToolbar" />

<st:cardPanel id="mainCardPanel">
<st:list id="mainMenu" sessionName="mainMenuOptions" height="100%"
nextPage="page3" >
<st:layout>
<st:field name="optionText" displayInList="true" />
</st:layout>
</st:list>
</st:cardPanel>

</st:panel>

--------------------------------------------------------------
page3:

<ewd:config isFirstPage="false" pageType="ajax"
prePageScript="getOption^ewdLessonScripts" />

<st:panel layout="card" title="Form">

<st:form id="demoForm" submitOnAction="false" scroll="vertical">
<st:fieldset title="Form demo">

<st:field type="text" id="xname" label="xname" placeHolder="your
name" useClearIcon="true" />
<st:field type="combo" id="api" label="Name"
method="loadGoogleSuggest^ewdLessonScripts" />

</st:fieldset>
</st:form>

</st:panel>

Thanks
Michael

[rtweed]

If you're running the example on desktop Chrome or Safari, you may
find that it's a browser sizing issue. Try resizing your browser by
dragging its borders around.

Sencha Touch 1 is very susceptible to panel height definitions and
this may also be what you're seeing.

I'm soon to start working on Sencha Touch 2 (the tag library will be
closely aligned with the ExtJS v4 one) and I'm hoping to see a lot
less of this kind of quirky behaviour - time will tell. In the
meantime, the only advice I can give is to work from examples that do
display OK: the ones in the documentation examples were tested on an
iPad. You'll also see a working example of the combo field in use in
the VistACom application that is included in the dEWDrop VM:

http://www.fourthwatchsoftware.com/

For details and background to dEWDrop, see:
http://groups.google.com/group/hardhats/browse_thread/thread/1da86e7419b9ab8d/3ceaf799a26fb85c?q=dewdrop&lnk=ol&

Rob

On May 21, 2:11 am, Michael Reach <michoelre...@gmail.com> wrote:
> Rod, I tried the functionality in the pdfhttp://gradvs1.mgateway.com/download/EWD_Mobile_Tutorial_Part2_857.pdf

[Sam Habiel]

Just a bit of warning for those people who want to develop code to
lookup patients in a production environment. (I spoke to George L
about this before).

1. You must send the IEN of the Patient (aka DFN) to the front end and
associate it with the Name. You are not guaranteed a name's uniqueness
in the database as different patients can have the same name. This is
not done in the code below.
2. WorldVistA uses different Patient Lookup code than FOIA Vista. The
code below emulates FOIA Vista not WorldVistA. See routine ORWPT2 to
see how WorldVistA does it (and FYI George Timson did not write that,
despite his initials being there).
3. There is no handling of merged patients in the code below. It may
work correctly though, as I think VISTA renames the merged patient;
but the data will be located at a different DFN. I don't know how CPRS
handles this right now.

Remember that selecting a wrong patient to document on is a pretty big deal.

Sam
---

[Rob Tweed]

Precisely why we need to see the development of a set of standard "official" VistA APIs for use by EWD developers that interface into EWD

I just used that example because it was some code I had to hand, not because it represented the correct way to get VistA patiets, but it demonstrated how to create a Suggest-box-like combo for such things. 

Rob

--
You received this message because you are subscribed to the Google Groups "Enterprise Web Developer Community" group.
To post to this group, send an email to enterprise-web-de...@googlegroups.com.
To unsubscribe from this group, send email to enterprise-web-develope...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/enterprise-web-developer-community?hl=en-GB.

--
Rob Tweed
Director, M/Gateway Developments Ltd
http://www.mgateway.com
------------------
EWD Mobile: Build mobile applications faster
http://www.mgateway.com/ewd.html

[Sam Habiel]

Thank you Rob.

In general, I would recommend using already existing code (like
ORWPT2) to do this kind of thing.

One thing that worried me thought when George first showed me this
code is the fact that there is no place to put a value (i.e. patient's
DFN) along with the entry, unlike, say, a plain HTML select where you
can specify a value. Did I miss it?

Sam

[Rob Tweed]

I neither know nor care - I am not a VistA expert.  You need to take this conversation to Hardhats - this is something for them to consider.  It's not an EWD issue

Rob

[Sam Habiel]

Absolutely. But I this question is apropos:

Is there a place to put a value in the comboPlus box so that you can
supply the patient's DFN in addition to his name, so we can positively
identify which patient in the database the user selected?

Sam

[rtweed]

Are you talking about <ewd:comboPlus> or the new <ext4:combo> tag?

The answer in both cases is yes - it's up to you what you put in the
options array text value.

Rob

On May 23, 4:46 pm, Sam Habiel <sam.hab...@gmail.com> wrote:
> Absolutely. But I this question is apropos:
>
> Is there a place to put a value in the comboPlus box so that you can
> supply the patient's DFN in addition to his name, so we can positively
> identify which patient in the database the user selected?
>
> Sam
>
>
>
>
>
>
>
> On Wed, May 23, 2012 at 8:39 AM, Rob Tweed <rob.tw...@gmail.com> wrote:
> > I neither know nor care - I am not a VistA expert.  You need to take this
> > conversation to Hardhats - this is something for them to consider.  It's not
> > an EWD issue
>
> > Rob
>

> > On 23 May 2012 16:37, Sam Habiel <sam.hab...@gmail.com> wrote:
>
> >> Thank you Rob.
>
> >> In general, I would recommend using already existing code (like
> >> ORWPT2) to do this kind of thing.
>
> >> One thing that worried me thought when George first showed me this
> >> code is the fact that there is no place to put a value (i.e. patient's
> >> DFN) along with the entry, unlike, say, a plain HTML select where you
> >> can specify a value. Did I miss it?
>
> >> Sam
>

> >> On Wed, May 23, 2012 at 8:34 AM, Rob Tweed <rob.tw...@gmail.com> wrote:
> >> > Precisely why we need to see the development of a set of standard
> >> > "official"
> >> > VistA APIs for use by EWD developers that interface into EWD
>
> >> > I just used that example because it was some code I had to hand, not
> >> > because
> >> > it represented the correct way to get VistA patiets, but it demonstrated
> >> > how
> >> > to create a Suggest-box-like combo for such things.
>
> >> > Rob
>

> >> >>http://groups.google.com/group/enterprise-web-developer-community?hl=....

>
> >> > --
> >> > Rob Tweed
> >> > Director, M/Gateway Developments Ltd
> >> >http://www.mgateway.com
> >> > ------------------
> >> > EWD Mobile: Build mobile applications faster
> >> >http://www.mgateway.com/ewd.html
>
> >> > --
> >> > You received this message because you are subscribed to the Google
> >> > Groups
> >> > "Enterprise Web Developer Community" group.
> >> > To post to this group, send an email to
> >> > enterprise-web-de...@googlegroups.com.
> >> > To unsubscribe from this group, send email to
> >> > enterprise-web-develope...@googlegroups.com.
> >> > For more options, visit this group at
>

> >> >http://groups.google.com/group/enterprise-web-developer-community?hl=....

>
> >> --
> >> You received this message because you are subscribed to the Google Groups
> >> "Enterprise Web Developer Community" group.
> >> To post to this group, send an email to
> >> enterprise-web-de...@googlegroups.com.
> >> To unsubscribe from this group, send email to
> >> enterprise-web-develope...@googlegroups.com.
> >> For more options, visit this group at

> >>http://groups.google.com/group/enterprise-web-developer-community?hl=....

>
> > --
> > Rob Tweed
> > Director, M/Gateway Developments Ltd
> >http://www.mgateway.com
> > ------------------
> > EWD Mobile: Build mobile applications faster
> >http://www.mgateway.com/ewd.html
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Enterprise Web Developer Community" group.
> > To post to this group, send an email to
> > enterprise-web-de...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > enterprise-web-develope...@googlegroups.com.
> > For more options, visit this group at

> >http://groups.google.com/group/enterprise-web-developer-community?hl=....

[rtweed]

ie just to spell it out:

.s options(no,"displayText")= whatever you want to display in the
field
s options(no,"value")= the value to associate with the displayed text
(and which is returned when the form is submitted)
and then you can add any other records into this array to provide
pointers back to the original database record

You control all of that, not EWD

Rob

[Sam Habiel]

Rob,

My deepest thanks. Emulating Lister functionality (LIST^DIC, a Fileman
API) in EWD was one big thing that I didn't know how to do. Hopefully
somebody will write (maybe me) a custom tag can encapsulate all of
this so all we have to do is say <vista:list file="2"> and there we
have it.

Sam

> --
> You received this message because you are subscribed to the Google Groups "Enterprise Web Developer Community" group.
> To post to this group, send an email to enterprise-web-de...@googlegroups.com.
> To unsubscribe from this group, send email to enterprise-web-develope...@googlegroups.com.

> For more options, visit this group at http://groups.google.com/group/enterprise-web-developer-community?hl=en-GB.
>

[rtweed]

As I said, we need people in the VistA community producing EWD-based
APIs and custom tags to encapsulate best practice and prevent constant
reinvention of wheels (with the added risk of subtle errors in some of
them).

Rob

> > For more options, visit this group athttp://groups.google.com/group/enterprise-web-developer-community?hl=....

[Zach Gonzales]

I shall offer my two cents. As someone who is developing code for use in a production environment I have these thoughts. Custom tags are great and the fact the Robs provides us mere mortals with a mechanism to extend EWD is fantastic. However like any tool there is the best tool for the job. 

After a little summit in January this year I spent about a month mapping out how to do as Sam suggests. Take a Fileman API and build a custom tag. I did not find a custom tag the most ideal way to accomplish my goal. For me integrating EWD with VISTA is most elegantly done by building wrappers around exiting Fileman APIs and/or VISTA RPCs. I could not find a reason to take it a step further and abstract this piece out to a tag. Too often these things change and/or need updating. For me the beauty of these two great pieces of software lie in the simplicity. Example, an RPC is updated, all I need to do is adjust my MUMPS code to take into account the change. Recompile and I am back in business. 

Now I am not saying that a custom tag is incorrect. To me it seems this extra layer only adds to the complexity of the application and eventually the ongoing maintenance. The likelihood that other developers will be asked to maintain and troubleshoot your code in the future is very high. I believe I owe future adopters code that has not been unnecessarily complicated by my desire to load it up with cool shiny stuff.

Let me give you an example, here is a piece of a MUMPS code(pre-page script) that uses Fileman's lister to lookup and filter patients based on defined parameters. Straight forward and its use documented in the Fileman Programmers manual.

 D LIST^DIC(2,,,"Q",500,,KBAZNAME,"B",KBAZSC,KBAZWRIT,"KBAZTEMP")

A bit more to make use of that call to build the list for the combobox...  

 N LIST S LIST=$NA(KBAZTEMP("DILIST")) ; abbreviate return list name

 N KBAZCNT S KBAZCNT=0

 F  D  Q:'KBAZCNT

 . S KBAZCNT=$O(@LIST@(1,KBAZCNT))

 . Q:'KBAZCNT

 . N NAME S NAME=@LIST@(1,KBAZCNT) ; Name (.01)

 . N KBAZWRB S KBAZWRB=$G(@LIST@("ID","WRITE",KBAZCNT,3)) ; wrd, rm-bd

 . S KBAZPATS(KBAZCNT)=NAME_"   "_KBAZWRB

 ;

 QUIT  ; end of EWDPERS

and finally the important bit to bring it all to life in the .ewd page...

<st:field type="combo" id="patient" label="Patient:" labelWidth="25%" method="EWDPERS^KBAZFHDC" panelHeight="400" />

I think this is a very clear and straight forward way to bring VISTA data into an EWD app, a way that is maintainable and adoptable. Those are my thoughts.

Rob thank you again for all the hard work and a stellar toolset to build cutting edge applications.

Zach 

> > To post to this group, send an email to enterprise-web-developer-comm...@googlegroups.com.
> > To unsubscribe from this group, send email to enterprise-web-developer-community+unsubscribe@googlegroups.com.

[Sam Habiel]

Zach,

My vision for having tags is as follows:
- We need to take experienced programmers out of the equation for
pre-Alpha software development. Users should be able to design files
and make forms quickly. They can do that right now in Roll and Scroll
Fileman, which is astonishing in the speed of making something useful.
Programmers are typically the worst at delivering something usable and
relevant. Let the user do that for you, and expand on his/her work.
- To enable drag and drop development in an IDE, where you just have
to say "I want to edit these fields" in a file, without having to
write code for every single field. Unfortunately, that's what CPRS
does.
- To enable reusability. If all you do is list data for pointer files,
why write the code several times? If you need to validate data in
forms, why don't you let Fileman do it, instead of writing the code
for each field by hand?

The concepts have been pioneered before in VISTA. VISTA will let
superusers design a file, create input templates (i.e. Forms), print
template (i.e. Reports) on the file.

For an example of mature drag and drop development in VISTA, look at
Fileman Delphi Components. I want something similar for EWD.

Sam

>> > > enterprise-web-de...@googlegroups.com.

>> > > To unsubscribe from this group, send email to

>> > > enterprise-web-develope...@googlegroups.com.

>> > > For more options, visit this group
>> > > athttp://groups.google.com/group/enterprise-web-developer-community?hl=....
>

> --
> You received this message because you are subscribed to the Google Groups
> "Enterprise Web Developer Community" group.

> To view this discussion on the web, visit
> https://groups.google.com/d/msg/enterprise-web-developer-community/-/f_KLzetdLLgJ.

>
> To post to this group, send an email to

> enterprise-web-de...@googlegroups.com.

> To unsubscribe from this group, send email to

> enterprise-web-develope...@googlegroups.com.

> For more options, visit this group at

> http://groups.google.com/group/enterprise-web-developer-community?hl=en-GB.

[Michael Reach]

Rob, I have an interesting application using this, and a question about IO. 

First the application: I wanted to duplicate the standard Fileman Inquiry (d ^DII, choose I). So I created an ewd page FMInquiry.ewd with two Google combo boxes, File and Entry. Type in the first, get a file from the FM ^DIC list of files. Once that's chosen, the second Google combobox Entry is made ready, to type in and choose an entry from that file. Once that's done, the Inquire button runs a DBS GETS^DIQ call, to return the values of all the fields, and loads them into a panel at the bottom. Works well, though I think the combo boxes needs some more listeners to handling things like up- and down-arrow and such and certainly the output can be prettied up a lot.

If anyone is interested, I can supply the code and pages; it could be improved. I don't think I can currently supply a link, as my dEWDropped machine is on a private network, unless someone wants to provide a place for them. 

Now the question: Another thing I wanted to try was to output the data using the classical CAPTIONED FM output. Unfortunately, it writes to the terminal, and I wasn't sure how to capture what it writes. So Bhaskar suggested to me to use a gt.m PIPES output to catch it, then reflect it back into a array, then send it to the ewd output. Works like a charm on my home terminal, here's the code:

inq(filen,entryn,output) ;

n cnt,DA,DIC,glb,p1

k output ; output array, returned by reference

d HOME^%ZIS ; set Kernel IO* variables for home device

s glb=$$ROOT^DILFD(filen)

s p1="test1"

open p1:(shell="/bin/sh":comm="cat")::"PIPE"

use p1

s DIC=glb,DA=entryn

d EN^DIQ

w /EOF

s output(0)=0

f cnt=1:1 read x q:$zeof  s output(cnt)=x,output(0)=cnt

close p1

q

However, when I try to do this in an onBeforeRender routine, I always get a Javascript error on the return. The returned Javascript is chopped up in a weird way:

<pre id="ewdscript">
Ext.create("Ex
t.panel.Panel",{html:"NAME: HEPATITIS B CORE ANTIBODY TYPE: BOTH SUBSCR
IPT: CHEM, HEM, TOX, SER, RIA, ETC. LOCATION (DATA NAME): CH;582;1 LAB C
OLLECTION SAMPLE: BLOOD FIELD: DD(63.04,582, HIGHEST URGENCY
ALLOWED: ASAP PRINT NAME: H.BCORE PRINT ORDER: 38.9 DATA NA
ME: HEPATITIS B CORE ANTIBODYSITE/SPECIMEN: SERUMCOLLECTION SAMPLE: BLOOD
         FORM NAME/NUMBER: MISC MIN VOL (in mls.): 10SYNONYM: ABHBC",id:"rslTxt
"}
);var addTo='Iresults';
var remove='';
if (remove === 'true') Ext.getCmp('
Iresults').removeAll(true);
if (addTo !== '') Ext.getCmp('Iresults').add(Ext.ge
tCmp('rslTxt'));</pre>
<span id="ewdajaxonload">
var ewdtext='' ; if (ewdtext
!= '') { if (ewdtext.substring(0,11) == 'javascript:') { ewdtext=ewdte
xt.substring(11) ; eval(ewdtext) ; } else { EWD.ajax.alert('')
    }
}</span>

Note the line wrapping (every 80 characters?) which wrecks the Javascript. I'm assuming that the IO device is not back to where it started. So my question is, is there a way to do this properly, calling a PIPES device but then resetting ewd's IO for the return?
Thanks,
Michael Reach
(By the way, if this can be made to work, I have a FM Print page ready to go as well.)

[rtweed]

Glad you got the combo-box working - sounds good.

Regarding dEWDrop in the cloud: I'm hoping we'll see it becoming
available for use in the new VHA Innovations Sandbox. Bill Cerniuk
gave an awesome presentation about this at the VistA Community
Meeting.

Regarding the piping side-effect: if, in your back-end scripts, you
open and use a device, you MUST first protect the TCP device that is
in use for EWD / m_apache. So, do the following in your script:

n io
s io=$io
...

Now open and use the device, and on closing it, do the following:

u io

That will correctly reinstate the m_apache TCP connection as the
principal device.

Also, I notice you've done the following:

d HOME^%ZIS ; set Kernel IO* variables for home device

If that changes the width and other properties of the principal device
(which is the TCP connection to m_apache), then you're going to cause
all manner of unpleasant side effects such as the one you're seeing.
Is this call really necessary? If it is, you're going to have to
discover what those parameters were before the call and reset them.
If possible, just leave the principal device well alone and don't mess
about with it.

Rob

[Michael Reach]

Got it! I don't need the full power of HOME^%ZIS and all it does. Just

s IOM=80 ; RIGHT MARGIN

s IOSL=24 ; SCREEN/PAGE LENGTH

s IOST(0)=60 ; SUBTYPE NUMBER, ien in TERMINAL TYPE file

is enough to fool Fileman into thinking that it's writing to a terminal, so that the Captioned output works. Thanks!

[Sam Habiel]

Mike,

I already wrote something similar. I don't recall how much I have
done, but I have solved your specific issue a couple of times. This
one doesn't use all the VISTA APIs for reading files back, but I have
used that code before. See ORWRPP for an example.

Here's the link to the code:
https://trac.opensourcevista.net/svn/EWD/ewdapps/DIINQUIRE/

Sam

> --
> You received this message because you are subscribed to the Google Groups
> "Enterprise Web Developer Community" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/enterprise-web-developer-community/-/ieK9pTpraasJ.

[Michael Reach]

Thanks, Sam. I'm getting a really scary warning from all types of browsers when I click on your link.

Michael

[Sam Habiel]

Oh! It's a self-signed certificate. Check it out yourself to assure
yourself that it's from the WorldVistA organization.

Sam

> --
> You received this message because you are subscribed to the Google Groups
> "Enterprise Web Developer Community" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/enterprise-web-developer-community/-/qVKT2nutENUJ.

[Michael Reach]

One issue that is maybe a question for Rob Tweed:

When I do my FM Inquiry, I post the result back to the page by placing the inquiry output in a session variable. That works okay if it isn't too big. If the inquiry result is more than 4080 characters, I get a gt.m error in setSessionValue^%zewdAPI

%GTM-E-REC2BIG, Record size (4967) is greater than maximum (4080) for region: DEFAULT,%GTM-I-GVIS, Global variable: ^%zewdSession("session",1801,"results") 

Is there a better way to do this - how does ewd handle large chunks of data?

Thanks,

Michael

[Sam Habiel]

Here's how I do it:

In the routine:
; Move to EWD Session global
d clearSessionArray^%zewdAPI("DIINQUIRE",sessid)
d mergeGlobalToSession^%zewdAPI($NAME(^TMP("EWDU",$J)),"DIINQUIRE",sessid)

On the page fragment:

<ewd:config isFirstPage="false" pageType="ajax"

prePageScript="INQ^C0EDIINQUIRE">
<ewd:forEach sessionName="DIINQUIRE" index="$lineNo" return="$data">
<?= $data ?><br />
</ewd:forEach>

Sam
PS: The M 95 standard specifies that the maximum global length of a
single node is 255 characters. Cache supports up to 32K, GT.M supports
up to 64K; but I think both companies don't recommend having anything
that large because of inefficiencies at the OS level having to do with
interactions with the Block size on the OS.

> --
> You received this message because you are subscribed to the Google Groups
> "Enterprise Web Developer Community" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/enterprise-web-developer-community/-/KODcp1baNXYJ.

[Michael Reach]

Thanks, that's good. I also note that you used CAPTION^DIQ instead of EN^DIQ, which makes it a whole lot easier because CAPTION doesn't deal with IO. How did you find it? I didn't see it in the standard FM documentation.

And is there an similarly non-device-y FM equivalent for EN1^DIP for the FM Print function? EN1^DIP is even worse than EN^DIQ; it actually asks you for a device and opens it. I've been trying hacks like setting %ZIS="N" (so it won't actually open the device) and IOP="whatever" to fool ^%ZIS into not doing anything... 

Thanks,

Michael

[Sam Habiel]

Mike,

I found CAPTION^DIQ by reading the Fileman code. It's not a public API
(PEP in RPMS parlance or public IA in VISTA parlance).

EN1^DIP by contrast IS a public API, and it's very well documented. I
don't remember, but I think you need to supply the variable IOP for a
device.
http://www.hardhats.org/fileman/pm/cl_dip.htm

Sam

> --
> You received this message because you are subscribed to the Google Groups
> "Enterprise Web Developer Community" group.
> To view this discussion on the web, visit

> https://groups.google.com/d/msg/enterprise-web-developer-community/-/Nfu_2npC-XwJ.

[Michael Reach]

I tried using Sam's setup, but since I'm using the ext4 tags, I tried something like this on the page fragment:

<ext4:fragment onBeforeRender="inquire^mkr">

  <ewd:forEach sessionName="InqRsl" index="$lineNo" return="$data">

    <?= $data ?><br/>

  </ewd:forEach>

</ext4:fragment>

But nothing shows up in the page.

I see in the %zewdSession global that InqRsl is loading fine:

^%zewdSession("session",1811,"InqRsl",0)=11

^%zewdSession("session",1811,"InqRsl",1)=""

^%zewdSession("session",1811,"InqRsl",2)="NUMBER: 253

            NAME: DG DEATH"

^%zewdSession("session",1811,"InqRsl",3)="  TYPE: public

            ALLOW SELF ENROLLMENT?: NO"

^%zewdSession("session",1811,"InqRsl",4)="  REFERENCE COUNT: 7

            LAST REFERENCED: JUN 24, 2011"

^%zewdSession("session",1811,"InqRsl",5)="MEMBER: DOCTOR,YOURNAME"

^%zewdSession("session",1811,"InqRsl",6)="MEMBER: COORDINATOR,ONE"

^%zewdSession("session",1811,"InqRsl",7)="MEMBER: DOCTOR,THIRTEEN"

^%zewdSession("session",1811,"InqRsl",8)=" DESCRIPTION:   This mail group receiv

          es the death notices for any paitent"

^%zewdSession("session",1811,"InqRsl",9)=" discharged from the ward as death or

          if the Death Date of the patient file has"

^%zewdSession("session",1811,"InqRsl",10)=" been entered using the DG Death opti

          on.  "

^%zewdSession("session",1811,"InqRsl",11)="  ORGANIZER: DOCTOR,THIRTEEN"

So I'm guessing that the problem is that the ext4 tags don't work this way with the ewd:forEach tag. So how should it be done?

Thanks,

Michael

On Friday, June 8, 2012 1:13:39 PM UTC-4, Sam Habiel wrote:

Here's how I do it:

In the routine:
; Move to EWD Session global
 d clearSessionArray^%zewdAPI("DIINQUIRE",sessid)
 d mergeGlobalToSession^%zewdAPI($NAME(^TMP("EWDU",$J)),"DIINQUIRE",sessid)

On the page fragment:
<ewd:config isFirstPage="false" pageType="ajax"
prePageScript="INQ^C0EDIINQUIRE">
<ewd:forEach sessionName="DIINQUIRE" index="$lineNo" return="$data">
    <?= $data ?><br />
</ewd:forEach>

Sam
PS: The M 95 standard specifies that the maximum global length of a
single node is 255 characters. Cache supports up to 32K, GT.M supports
up to 64K; but I think both companies don't recommend having anything
that large because of inefficiencies at the OS level having to do with
interactions with the Block size on the OS.

On Fri, Jun 8, 2012 at 9:57 AM, Michael Reach Michael Reach wrote:
> One issue that is maybe a question for Rob Tweed:
> When I do my FM Inquiry, I post the result back to the page by placing the
> inquiry output in a session variable. That works okay if it isn't too big.
> If the inquiry result is more than 4080 characters, I get a gt.m error in
> setSessionValue^%zewdAPI
> %GTM-E-REC2BIG, Record size (4967) is greater than maximum (4080) for
> region: DEFAULT,%GTM-I-GVIS, Global variable:
> ^%zewdSession("session",1801,"results")
> Is there a better way to do this - how does ewd handle large chunks of data?
> Thanks,
> Michael
>
> --
> You received this message because you are subscribed to the Google Groups
> "Enterprise Web Developer Community" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/enterprise-web-developer-community/-/KODcp1baNXYJ.
>
> To post to this group, send an email to

> enterprise-web-developer-comm...@googlegroups.com.

> To unsubscribe from this group, send email to

> enterprise-web-developer-community+unsubscribe@googlegroups.com.

[Michael Reach]

An update on my earlier comment is that I've been trying to get the results to appear in various types of ext-4 fields, including textareafields and htmleditorfields. I had high hopes for them because you load them by Merging in an array. Unfortunately, in both cases I still got an error for more than 5040 characters, and I see that the code in ^%zewdExt4Code just concats the input array into a string, then tries to put it into the session global. 

So I'm still trying to find what would work.

Michael

[rtweed]

This will be fixed in the next build - hopefully coming out soon

Rob