Is this the way forward?

Oh dear, it's Forms Designer and SuperLayer's illegitimate offspring > Aiiee! Somebody set up us the bomb! All your base are belong to us! Launch all Zig for great justice.

Nice to see that the whole thing is just another layer of code between the kernel and the developer. More bugs are inevitable (nobody's that good). Will the conversion tools to VIP from Native be as 'reliable' as the ones for SL?

I appreciate that the diagrams are pre-Alpha code but it's not very pretty is it? The layouts are inconsistent, as are the colour schemes, and much of it is still in horrible PRO-IV 4.0 GUI look and feel.

I just want to know - what do we do if we don't want to use it? Search the generated (see fig 1 in the document) source code for what the new features are and then hack?

But I/we want to see the code, running, on our desktops, before we can really make a judgement on it all. Looking forward to PRO-IV posting an open Beta version on this site

Dan Shannon

Could you please be a little more negative and judgemental oh great one !

Do you actually read content or are the first couple of words all you can manage.

These guy's could always revert to complete non-cominication and that is not good for us the development comunity.

Lets judge VIP as we understand it and get to touch and feel it.

Perhaps you didn't read the content of Dan's message he said 'But I/we want to see the code, running, on our desktops, before we can really make a judgement on it all. Looking forward to PRO-IV posting an open Beta version on this site '

And perhaps you just read the first couple of words of his post.

Maye eye sugest befor u starte swingin yur andbag & kwestioning der abilitie ov poeple two reed dat u adress yur speling & gramma, itt iz apppallin.

Not listening to the comments from the user community be they negative or positive amounts to non-communication.

I agree with Dan.

Dan for president.

Steve

At first glances it does look like a 'new' version of superlayer. Not too sure about all this 'new' layer thing and a new source code set. Isn't this going to make things worse or will VIP code be 'genned' directly into the genfile?

Dan is correct in noting that there is no standard between screens, although it is hard to actually make out what is on the screens due to the low res. images (not sure why they are so blurry or is it my graphics card?). On the one screen that is 'clear' however I cannot see any 'alt/hot' keys to get between fields, I hope that is going to be included later. It does not look like the standard 'windows' env. either.

However, to be fair this is a pre-Alpha look and therefore things could radically change, as the document says.

The work around 'locking/booking out' functions looks like it could help alot.

Thank you for 'sharing' the first look with us and hope you will continue to update us.

Rob D

Blurry pictures and sales talk aside, interesting about this discussion-document is where Pro-IV is positioning itself with regard to other environments.
As the document states 'Once a function is built (regenned) within VIP the source code will no longer exist in the native form'. This implies that continuing with Pro-IV on their chosen path, means that a radical choice is made for a new environment. With all associated problems of (initial) instability and lack of trained personnel.
Even if the migration is flawless (and Pro-IV does not have the best of track records here), anyone in a position to decide on developmenmt environments now will have a clean point at which the pros and cons of competing environments can be set against one another. And then the scales might easily be tipped against a new unproven environment for which no personnel can be hired. The choice to abandon an existing project and to go with a mainstream package is then quickly made at non-technical board-room level.
I just want to remind Pro-IV of the respons to a question not that long ago on this board for any new projects started in Pro-IV.

We might have to look for a new job.

Ooh I'm hurt! At least I'm willing to put my actual name to these things...

Anyway, as I said I want to see it before I form any final judgements, but the model DOES look a bit like SL to me. I truly hope that it IS the tool we're all waiting for, meanwhile my cynicism remains.

Dan Shannon

More structure to work around and no access to the source code. This would scare me if I thought that my only saleable skill was writing Pro-IV code.

I have attached the original gifs that are not too fuzzy thanks to adobe pdf.

A couple of points to mention.

VIP is not an abstraction in the SL sense we do not create
native source via a mystic engine process that is difficult to customise.

The code that VIP deals with is native plus extensions when the 'push' takes place your code is moved in to the existing boot files for gen with minor reformating of logic (comments and steps) and the generation of unique maps (interfaces). The sequence of fields files and control breaks are created from the VIP structure file which guarantees the integrity of your function.

The use of a structure file has a number of major benefits in that structure clipboard (cut copy paste) and structure templates can be provided which will improve the reuse and manipulation of code on a structural level.

Yes it is our intention to destroy the native source image as part of the function build for the protection of function integrity.

The function build process is as fast as Dev Studio much faster than SL but not as fast as native. A couple of seconds extra on a gen is a small price to pay for tighter more productive environment. In the future it may be possible to gen direct from the VIP boots instead of native but this is defiantly some way off.

Version 5.0 will ship with Dev Studio, Native, SL allowing for a controlled evaluation of migration, testing, training etc.

VIP does not take away the ability for the current PROIV developer to create code. It is designed by developers to make the process faster and less prone to error as well as providing the framework for new technolgies provided by PROIV in the future.

This product is most definitely the grandchild of Native, Super Layer and the child of ProAIDE and Dev Studio but a ‘bastard’ is not a nice thing to say about one so young. Forms designer will form part of VIP but will be changed to deal with structure fragments instead of the whole function and so make use of the delete paste structure processes (much better that the current model)

I really would welcome some constructive criticism and thoughts on this product and will provide more detail as the project/discussions progress.

Neil

Thanks for the clarification - this is good news re the method of code generation.

Given that VIP will (in some form or other) generate Native code, this must mean that the bootstraps will remain and be updated to cope with any new features (though my understanding from v4.7 is that the set properties are an abstraction via logic, and so don't actually form part of the bootstraps themselves). Does this mean that the bootstraps will continue to be available to those who have proper access to them?

Please do post more news as it comes, I know I check this forum far more often than either the proiv.com or myproiv.com sites (daily vs every few weeks) and I'm sure that's the case for many others.

Is the version control system the same as (or similar to) the one that was in ProAIDE?

Is the Native source going to be left in place post-gen from VIP or will it be created, genned and then immediately deleted? At least in early releases it would be good to leave the source code in place as it was created so that developers have a better chance to find bugs, and PRO-IV support can see what code we have generated.

Any idea on when some kind of public trial might be available? (However buggy, I'm sure lots of the people who contribute here would like to get a feel for the new product so we can do some planning for how and when (and if) to convert over to VIP, as well as to provide some feedback from our part of the PRO-IV development world.

Cheers

Dan Shannon

Best post I've seen for a while. I'm now drowning in positivity.

Now I understand it a little better and it hurts to say this, but it looks nice. It appears we are all going to unlearn ProIV as we know it (not a bad thing) and embrace our new sibling into the fold. I hope that the Developer Studio type screen is dropped soon. Good to see the use of tabs instead of 'drill down' windows and I see proper windows list boxes have crept in or are they paging screens?

Let's hope our new bundle of joy doesn't turn into a teenage terror.

Remind us once again, when can we expect to have a pre-release of this made available to the community?

Respond to this Neil and my positive karma may last for the rest of the day.

Neil for Dali Lama.

Peace.


Steve

I've been following the thread on VIP and with the screenshots have a little more of an idea of what it is now.

One issue for us in moving to VIP would be the ability to re-write our 40-odd utilities which use bootstraps for development and maintenance tasks, eg finding all functions that use a file and a variable, and then add the functions to our internal change history/control databases.

We have also written our own functions for tracking changes to our production system, controlling exports of functions, checking for missing exit links and globals, and so on.

From what I read of VIP, we won't be able to access the VIP files anymore.

Will VIP have any search facilities by file/fields used, etc?

Also, we have 13000 functions to maintain, and have had to write our own regen functions because the
bootstrap keys only allow a 4 digit sequence number. How well will VIP handle this large a function base?

The object property extensions are held in a new bootstrap file that holds initial states for an object and a default record to guarantee a unique tag reference within the function. Bootstrap pointers are also stored in this file and this is what makes publishing it dangerous.

VIP will through it's API allow you write/modify your existing tools to make bulk/specific changes to the source but will also provide access checking and audit as a by product and more import will help to protect the integrity of the code.

Version control is not part of the first planned release of VIP only the booking out to project concept. We will however provide the stubs for third party version control systems to be 'hooked' as we did for Dev Studio.

I feel that we will probably not delete native source post build initially as it would give more confidence to users knowing that a safety net exists. One idea is that a value variable switch will toggle the behaviour, but will result in the re-migration of the function when edited within VIP. So the cost of the safety net is a slower function load time after build.

Busy building alpha .8 I'll post some more A.S.A.P

I feel your energy man!!

We are using multi column list boxes which also permit multi item selection. The Dynamics and Event views are paging screens !!

As to a pre release, as soon as possible internally .8 alpha by the end of this week .9 in two weeks. If I can get agreement from above I will look for external participants soon after. The current schedule is to commence beta May 1 so that we can have three to four months of trial.
The base functionality will be complete by May 1 but
'plug in' items such as tools, Forms Designer and the API will be released during the trial with the online help/documentation released at the end of the trial period.