World: r3wp

Is your PDF sepcified via an XML specification?

Robert, xfdf is a deprecated format once used by Adobe to specify 
the contents of fields in a PDF.  So, the above xfdf file will populate 
the fields TextField1, TextField2, syupdfid with $fname, $surname, 
and $syupdfid ... ( well,  I will replace those before I send the 
pdf. )

I will also expand the href to "http://www.compkarori.co.nz:8000/pdfs/testpdf4.pdf? 
+ now (  I do this stop caching the form contents )

So, I send this tiny xfdf file to the browser.  the browser loads 
up the acrobat plugin.  Acrobat now reads the pdf on my website as 
specified in the href field, and then fills in the fields in that 
pdf with the values as specified in the xfdf file.

I have a submit button on the pdf which then sends the data back 
to me.

You can test this by logging to http://www.compkarori.co.nz:8000, 
and then using the "locate" button, ( leave the form blank ) and 
then select any dummy patient.  Then on the bottom left menu, click 
on "test pdf" and then submit.

Note that xfdf does not work with Acrobat PDFs created by Adobe LiveCycle 
.. they want you to move up to their much more expensive forms technology.

Any known issues running Cheyenne on Windows XP 64 or Vista 64 ?

Never tried and I didn't received any feedback from users on that 
platforms.

Ok, I'll investigate further with the user ...

Unfortunately I don't have access to either of these to test :(

Maybe someone here using one of these 64bits OS would be kind enough 
to run a few tests for you?

That would be good ....Just want to make sure it works.

well, as a temporary measure, if my application can't connect-to 
Cheyenne, it will drop back to the REBOL micro web server which does 
work.  Maybe the user has changed the default port, or has a firewall 
blocking it ... will have to find out.

Ok, seems that the user moved his Cheyenne binary without taking 
my httpd.cfg which I provided.  And so the listen port changed to 
80 which is the default that Cheyenne creates.

I wonder if the default port should be something else as on Vista 
and Linux, that port is not allowed by default.

Everybody expects from a web server to run by default on port 80, 
that's the specification. From RFC2616 : "HTTP communication usually 
takes place over TCP/IP connections. The default port is TCP 80 but 
other ports can be used.".

Regarding httpd.cfg file, I'll look on how to avoid writing it down 
on disk when running from a custom encapped binary.

An improvement for Cheyenne on Vista could be to display a standard 
OS security requester asking for admin pass when Cheyenne  needs 
to run on port < 1024.

How about instead just show in the system icon tray an information 
menu item to show what port it is listening on?

Not sure that's the right place. It's supposed to be a static information 
from the user POV, so the documentation might be a better place.


Btw, after reading again your posts above about that issue, you should 
have provided an encapped Cheyenne with your own httpd.cfg config 
file built-in (instead of using the default one). Moving the binary 
aournd wouldn't been an issue then.

The yellow tooltip message when mouse is over the systray icon could 
be a good place. Instead of "Cheyenne is running" could be "Cheyenne 
is listening on port(s) ...". I'll think about it.

Actually I am using your encapped binary and not mine as the localhost 
server doens't need odbc :)  I take your point though.

My server app ( with the binary in the browser ) is now able to prefill 
pdfs, and then when submitted back to the server, able to display 
previously filled in pdfs :)

I think "cheyenne is listening on port " would be good because I 
run a number of cheyenne instances launched by different apps, so 
I can't tell which one is which unless I see the port information.

hhmm.. I'm getting this

7-Mar-2009/21:17:18+13:00 : make object! [
    code: 507
    type: 'access
    id: 'no-connect
    arg1: 127.0.0.1
    arg2: none
    arg3: none

    near: [server: open/binary/direct rejoin [tcp:// server-address ":" 
    server-port] 
        set-modes
    ]
    where: 'connect
]

I start up one instance of Cheyenne on port 8000 which is okay, and 
then I start another instance running in port 7999.  The one I connect 
to 2nd produces the crash log.

I am running two instances because the web app uses the same database 
name

Reproduced it on a different pc.

that line comes from task-handler.r

7/3-21:59:42.822-## Error in [OS-API] : OpenSCManager failed : Access 
is denied. !
7/3-21:59:42.826-[boot] Cmdline args : -v
7/3-21:59:42.835-[boot] Processed    : [verbosity 1]
7/3-21:59:42.838-[boot] Boot flags   : [verbose]

7/3-21:59:42.840-[boot] Data folder  : %/C/cheyenne-r0919/Cheyenne/
7/3-21:59:42.906-[uniserve] Async Protocol FastCGI loaded
7/3-21:59:42.936-[conf-parser] Loading extension: mod-internal
7/3-21:59:42.940-[conf-parser] Loading extension: mod-extapp
7/3-21:59:42.943-[conf-parser] Loading extension: mod-static
7/3-21:59:42.948-[conf-parser] Loading extension: mod-action
7/3-21:59:42.952-[conf-parser] Loading extension: mod-fastcgi
7/3-21:59:42.955-[conf-parser] Loading extension: mod-rsp
7/3-21:59:42.960-[conf-parser] Loading extension: mod-ssi
7/3-21:59:42.963-[conf-parser] Loading extension: mod-alias
7/3-21:59:42.972-[uniserve] Starting RConsole...

7/3-21:59:43.003-## Error in [uniserve] : Cannot open server RConsole 
on port 9801 !
7/3-21:59:43.006-[uniserve] Starting Logger...

7/3-21:59:43.009-## Error in [uniserve] : Cannot open server Logger 
on port 9802 !
7/3-21:59:43.012-[uniserve] Starting HTTPd...
7/3-21:59:43.016-[uniserve] Starting task-master...

7/3-21:59:43.019-## Error in [uniserve] : Cannot open server task-master 
on port 9799 !

are these ports fixed and so I can only have one instance of cheyenne 
running?

Multiple running instances :


1 ) Cheyenne uses a port translation method for task-master to avoid 
clashing between Cheyenne's instances. This translation is currently 
triggered by the -p command line option specifying on which port(s) 
Cheyenne should listen. So the 'listen keyword in config file doesn't 
trigger the translation. After a quick look, it should be fixable.


2) Logger and RConsole services ports are not translated. This should 
be fixed too.


3) As a consequence of 1) & 2), Cheyenne can't currently run multiple 
instances on the same machine.


I am running two instances because the web app uses the same database 
name
 :


4) I very well aware of this issue and I intend to find a solution 
asap.

OpenSCManager failed : Access is denied
 :


5) I should load that routine! only if trying to run as a Windows 
Service without having admin rights.

I'm looking for 4) first because it's the quickest and cleaner way 
to solve your issues.

What if I use different names for the database, and then alias them 
in the webapp init ?  Then could i just run the one Cheyenne?

no .. that won't work.

I don't understand what's the problem with database names?

My webapp uses 'emr for the database name.

for one user emr points to one database, but for another user it 
points to a different database

So, to use a single instance of cheyenne, I have to go thru all my 
source and change the database name so that it's different each time 
I want to run more than one instance of this web app

I guess I could use remark for that.

You've set up one database per user?

I'm working on the support of per webapp databases definition instead 
of being global. So you could have a 'emr database definition different 
for each webapp (while keeping the same name in sources).

I have a demo database that contains dummy data ... anyone can access 
it.

I have a real database which I don't let anyone except myself access 
:)

so one set of users access the demo website, and I use the other 
one.

I see, so the patch I'm working on should solve that. It should be 
available tomorrow.

Thanks.

Graham, I have a working patch that supports setting same DB virtual 
name to different connections URL per webapps. Here's an example 
definition of 2 webapps using this new feature :

	webapp [
		virtual-root "/curecode1/"
		root-dir %//dev/curecode/
		locales-dir %private/locales/
		
		databases [
			bugs	mysql://[root-:-localhost]/bugs1
		]
	]
	webapp [
		virtual-root "/curecode2/"
		root-dir %//dev/curecode/
		locales-dir %private/locales/

		databases [
			bugs	mysql://[root-:-localhost]/bugs2
		]
	]

So, in order to reuse the same code for your EMR app but branching 
on 2 disctinct databases, you'll have to define 2 different webapps.