15 replies to this topic

[Cleve Haynes]

Does anyone know how to check the existence of an ascii file before reading
it in ProIV, without operating specific commands?

If you try to open an ascii file that does not exist, a message appears and the function bombs out.

Reading the file in a global update stops it bombing out, but we
want to prevent the error message appearing and inform the user that
the file name they entered does not exist.

Thanks,

Cleve.

[Rob Donovan]

Hi,

There is a couple of ways.....

SYSF(&#@CHKFILE,'rob.txt',#STAT)

#STAT = -1 File Does Not Exist
#STAT = 0 File Exists


Or on UNIX platforms

#STAT = SYSTEM('test -f rob.txt')

#STAT = 256 File Does Not Exist
#STAT = 0 File Exists

The SYSF is a better command as the other command has to start a new process to execute the test command which if done many times can cause performance problems.

Rob D

[Steve Kiernan]

Providing you are totally GUI, then you could try to do it using a dll - that's how we do all these sorts of things

Steve

[Rob Fantini]

Steve,
could you post some code which shows how you work with
'dll' in pro4?

[i'm 100% caracter mode but curious].

Also were you 100% green screen at one time? if so how
was the learning curve to gui?

Rob

[Rob Donovan]

Hi Rob,

DLLS:
Steve put a post a few days ago about using DLL's (see post Windows Machine Name). However I could not get it to quite work, but that is probably because I'm not too good at C++.
I could not get the sampdll.dll to work that comes with PROIV either. The message box pops up OK but then the whole PROIV client gets a GPF and crashes....

Maybe Steve has some ideas....

GUI:
We are just starting to convert things into GUI.

There is not really that much of a learning curve. And we still beat other languages by miles in development times!!

The major thing is finding out the solution of how to make PROIV actually do what you want.
There has to be alot of LSCALLing and and careful field jumping to be done.
Also there is a whole new list of bugs/workarounds to find!!

We went for the full GUI with bitmaps and backgounds rather that just using the standard 'gray' buttons GUI. Like the HRS system.

This adds a bit more complication as the graphics need to be designed.

Make sure only 1-2 people actually design screen layout/bitmaps so that they are all 'simalar' as a good GUI system should have all screens having the same design.

We used Adobe LiveMotion for designing the graphics, it's very good.

Also, make sure you use the 'FlickerFree'& 'EnableRightClickMenus' settings that I found a few months ago (see post further down), as this makes things alot smoother and fluid.

Allthough the Client seems to run on Win2000 it is not yet supported.

All in all, it opens up a whole new environment for your application.

There are supposed to be alot of new things in the new 4.7 release of PROIV regarding the GUI, so lets hope thats out soon.

We started doing demos etc on the basic Windows Kernel of PROIV and later found once we tried it on the UNIX kernel that there are a couple of bugs appear only in the UNIX kernel.
We a currently still awaiting a new UNIX kernel to fix these probelms as we cannot proceed any further untill then.

Hope this is usefull,

Rob D

[Steve Kiernan]

Hi Rob,

as Rob Donovan mentioned, there is an example already under this post.

We converted from green screen when version 3.0 was released as we were put under pressure from our users (what do they know ?)

It wasn't too difficult - using globals in later version helped too.

We use most of the gui features, but we use dll's extensively where pro-iv is lacking (radio groups, message boxes, reading files from pc's, copying files and generally interacting with the windows API)

We also spent some time tarting up the screens and making full use of proportional fonts - you do have to be careful if you mix your fonts as pro has big problems if 2 fields using different fonts happen to overlap.

I hope this helps.

Steve

[Steve Kiernan]

Hi Rob,

you do have to be very careful - pro-iv does not like it if you walk over its memory allocation which is why you must define any scratch variable you pass to or receive from a dll (not sure pro-iv mentions this anywhere in documentation though !).

Could this be your problem ?

Steve

[Rob Donovan]

Hi,

No, all my vars are defined.

I knew about that from my kernel links with our UNIX kernel.

Thanks though,

Rob D

[Steve Kiernan]

We couldn't get sample.dll to work either !

Steve

[Rob Fantini]

Steve,

Thanks for the info! I don't know if i'll port to
gui or not. But its great that you posted the info, i printed it for
future reference.

Rob

[DARREN]

ProIV Inc/Ltd has developed a Character based to GUI
conversion tool. It does a great deal of the conversion
automatically that would otherwise take hundreds of man
hours. It was developed from the tools used by the Resource
Link development team. It only works on native ProIV source
(not SuperLayer). Contact ProIV Ltd at St. Ives (01480 494 330)
or ProIV Inc. in Irvine(949 823 1000) for further details.

[Rob Fantini]

Darren,
Thanks for the info.

Have you used this tool?

Approx what is the price?


Has anyone else the price or experience with this tool?

Rob

[DARREN]

Hi Rob.

From my e-mail address you can probably tell I work for
ProIV. In answer to your question regarding my exposure to the
tool, I was one on the developers who put it together and even
if I say so myself, it's pretty good.

Why don't you give me a call on 949 823 4707 if you would like
to progress this further and we can set up a demo for you over
a web cast.

Cheers

Darren

[Glenn Meyers]

Hi!
I have had the experience of living with the 'tool' that wrote this piece of software, when I first started as the trainer at PROIV in California. .
Seriously, Darren may be one of the best PROIV coders on the planet (but don't tell him I said so).
Except for his obvious confusion about cars and which side of the road to drive them on, if he says its so, take it to the bank!

Be seeing you!
Glenn