OML can be used to hide or show fields conditionally.

In DE6 & DE8.5 the OML show() / hide() also applies on printout of the form.

In LE9 the OML show() / hide() does not carry through to printout.

Example:

Form with  fields: ItemDesc ; ItemDesc2 ; Options ; OptionIND

ItemDesc is virtual Text and autofills with the radio button 'Options' chosen value.

ItemDesc2 is Text allow entry 

Options is a Radio button with Values: OptionA; OptionB

OptionIND is Number with derivation: if(Options = OptionA, 1, 2)

OML: OptionIND; ValueChange

define "t" text .

if OptionIND.value = '1' then

ItemDesc.show() .

ItemDesc2.hide() .

else

ItemDesc2.show() .

ItemDesc.hide() .

end

t := RecordSave() .

-------------------------------------------------
Form View - works as expected
ItemDesc is shown and ItemDesc2 hidden when Options value OptionA is selected and vice versa if Options value OptionB chosen
Only ItemDesc OR ItemDesc2 is visible - never both at the same time.

Print  - ignores the OML

Both ItemDesc and ItemDesc2 show

-------

plz make it possible to download Your app for testing. if possible for sure. thank You!

TestApp attached

Blank user name/passw

Order_entry and Order_items_entry

got it! thank You! 

OML has no effect on printing. printer rendering is not the same as GUI manipulation. Use a virtual field with a derivation that reflect what you want to achieve.

In DE6 and DE8.5 OML show / hide does work on printout.

DFW up to 6.53 was developed in Turbo C/C++. Which went "bust" so DataEase had to convert to Microsoft C/C++ in 7.0 which was a big job. Borland (Turbo) was always a much better compiler/environment than Microsoft and did things much more the "DataEase" way than Microsoft that did it the techy way.

This should not really work in 6.x either but its quite intriguing that it does. We took over from 7.1 and this was a well established "Practice" in 7 onwards and its not something we will look into as there is many other ways to produce conditional printouts etc. in DE9. 

In many ways it showcase the madness of using a GUI format to generate prints which in many ways was a big downfall in DFW. 

Imagine if DFW had simply come with text based DQL/Reporting like DFD instead....

Just to make sure this is not something we inadvertently switched off while debugging OML I tested it in 7.1 and the result is the same.

OML is not activated when you print (screen print is not print).

We suggest looking into alternative to achieve what you want as we will not investigate this or "fix" it. This is a functionality that is over 20 years old and most people that use DataEase don't use OML much anymore. It was a distraction in the way of DataEase and will "die" with DFW. Future DataEase version will use HTML/Javascript etc.

All i know is that with DE6 and DE8.5 the form GUI whether defined as a Form or Report (Print or Live) does allow for conditional OML GUI manipulation for fields/text/object display properties.
Whatever GUI changes are seen on screen are then also seen on printout - which is as expected - WYSIWYG
This provides far more than what can be done only with virtual fields.

If there is no way of having the same OML GUI changes seen on screen also being on printout then LE9 is not WYSIWYG.

For the basic example above the only way of achieving this with field derivations is to create a completely separate Form/Report which only shows the choice outcome and all the additional work to open the form/report with relevant query keys.

It will work but is a step backwards as it should have been possible directly on the original form.

I'm not sure what we "argue" about here because it works the same in 7.1, 8.5 and LE9.

The fact you said it worked in 8.5 made no sense, so tested it in LE9 .


And as you see it paint the first column red.

To be hones, this is precarious stuff as your printer driver, windows version, compiler version etc. all is part of generating printing so some old PDF printers for instance won't do what they are told etc.

This is printing via Microsoft Built in PDF printer in Windows 10. Other drivers might not give the wanted result.

But in genreal OML is not an ideal way to make these things but nothing has changed and it works/doesn't work as before.

1. Ok, if OML is not the way to do it on LE9 then what is the LE9 alternative to conditionally hide a field? 

due to the war we have blackouts constantly in Ukraine.

Low energy consumption of DataEase applications help us to overcome!

Use DataEase to stop the war and carbon dioxide emissions!

Hiding fields during printing reduces usage of printing consumables!

we are voting for HTML not OML in new superb low energy DataEASE!

tested: old DFD foerever! in HTML now.

*"techy way" must die!

we are tired enough to test ... we demand new DataEase not ms alike DBMS ... sorry

Thx to DataEase team and Ulric for their great job!

SetState function triggered in a virtual field derivation or on a button can also conditionally hide or show fields on screen.

  SetState("ItemDesc1","Hide")

Unfortunately this also does not carry through to printout.

Field colour changes applied by conditional OML do carry through to printout.

LE9 print WYSIWYG only applies if fields are not conditionally shown or hidden.

Neither OML or SetState etc. was created for PRINT.

It is GUI functions and the only reason it works in print is luck/un-luck.

Nothing has been changed in LE9/DE9 for this and what works and doesn't work is not only down to DataEase but also the printer driver and Windows as this is a stack.

Obviously we endorse people exchanging ideas on how to achieve the end result but we won't work on "fixing" this in the FRM model.

You can generate prints with HTML/JavaScript etc where you can achieve anything you like and the future of DataEase for both GUI and Print/Production is text based generation i.e. HTML/JavaScript/Text or any other text based format.

We use DQL's everywhere from producing HTML/XML/JSON/JavaScript etc....

Going from DE6 to DE9 will be a lot of changes but the train to reflect on features in DE6 that is missing in DE9 should be re-implemented or fixed has left the station decades ago.

The book on LE9 development is closed and we are now simply finishing the delivery of a stable and supported version

Hi Sam

"Field colour changes applied by conditional OML do carry through to printout".

So, quick fix...set field colour properties (font, border, shading etc.) to white when the status is set to Print ;-)

Kind regards

Josef

Hi Josef
For the scenario that is required that would not work.
Two fields are placed on top of one another. One is virtual with a default option value and the other allows entry.

On initial form open the entry field is hidden and default virtual field is visible.

If the user wants to edit the value then then the user must select an "Edit" option and the virtual field is hidden and entry field is visible.
User can enter required value.
This is necessary as the requirement is that default values must be maintained and edited by exception with a record of when edits have been done.
To the user it looks like the "Edit" option allows the default value to be edited.
They can now print the form with the edited value. Unfortunately LE9 print shows both fields instead of only the visible field.

Another option would be if the original defined field property can be changed from "No Entry" to "Allow Entry" - Is this possible in LE9?

"The book on LE9 development is closed and we are now simply finishing the delivery of a stable and supported version"

Yup, we need this at least for now.

For sure we are very experienced of pretty tricks with bit and bytes on machine 1 and 0 level but it is not on demand today.

"how many angels can dance of the point of a needle" ... even more "D'Israeli goes on to say, "The reader desirous of being merry with Aquinas's angels may find them in Martinus Scriblerus, in Ch. VII who inquires if angels pass from one extreme to another without going through the middle? And if angels know things more clearly in a morning? How many angels can dance on the point of a very fine needle, without jostling one another?"

the problem mentioned is easily solved using ordinary DQL for DFD 2.5... without subforms as in DFD 4.2 ..4.53

thx to DataEase team a lot!

And there you have your que.

Instead of thinking that what "works" in DE6 should be the same in LE9/DE9 that maybe things has not regressed but rather progressed over the last 30 years.

The truth is that DFW users had to be "wizards" to achieve things as the product and supporting organisation was so difficult and inflexible.

All these workarounds that was "necessary" back in DFW 5,6,7 is now a problem as nobody can support moving forward exploits of corner cases, bugs, and design mistakes.

We don't recommend migration from anything before DFW 7.2 simply because the the focus of the development and scope in DE8/DE9 is not along the thinking of DFW 5.x - 7.1.

To be honest, we don't really think that much is gained by moving a 25 year old design into a new tool as it will still be outdated so rather than spend a lot of time to get old "tricks" to work in a much newer version more will be gained by simply making the GUI again with modern thinking and methods.

Our "best practice" is to think of your application as a Database rather than an application and develop new functionality over the same data that you share with your old App during development and step-by-step make your old App obsolete. 

There is more new functionality in DE8 than there was in DFW 5.x to 7.2 and there is twice as much if not more again in DE9.

SetState() has been available since early on in DE8 and have both Enable, Disable, Hide, SHow etc. Combined with SetStyle one can even make it look like its enabled and disabled with style rather than the horrible rect.fill.color crap etc.

Another solution would simply be to not print the form but print a report based on the same design. 

It is a big mistake in DFW that they assumed that print and forms was the same and used the same technology. Our focus has been on making forms good at being forms and reports good at being reports rather than constantly make one suffer because of limits in the other.

as to "OML show() / hide() does not carry through to printout" the solution is obvious. You transform all binaries using simple rules and methods of coding in 0 and 1 to get desired result. no stupid search in giant list of functions and etc. of modern non-effective software in comparison to old good architecture of IBM PC XT with 1 K RAM ;) IT is simply literature... illustrated by windows and mouse clicking. Is it clear ? For everybody! 

DFD is closer to coding in 1 and 0 than ... let it be an DFW 

My 1984 magisters investigation was dedicated to finite automata (any software is that thing  ... Turing machine for example) and constructing minimal finite automata corresponding to given automata mapping ;) that is why you all have to convert given database of 1 and 0 into datatabase of 1 and 0 to get image on desired image on the screen of your display or on the piece of printed material ;) it is very easy and you don't even know those long names of functions or tools  like ... used in comments above. You have to know that 1+1=0 with one switched bit in register or ... on punched paper tape.

It seems to me and I am fully confident that Java or HTML will be forgotten very soon and all software will be located in our brains connected by ..telepathy.

Open BCI is on the march ... The letter C will disappear very soon too.

DataEase is the only suitable idea in the case of direct brain to brain interface.

Do you use complex tools while thinking ? No! 

??? ????! )))))) = no exact English translation from Ukrainian ))))))))))) but transmitting thoughts from Ukrainian brains to English speaking ones will be exact  and succesful in the case. why ? we all have the same architecture and something like 1 and 0 (may be one state more ... for no operation or no value)

the End : the problem of "OML show() / hide() does not carry through to printout" has the solution even in LE9 case. 

Yeah, understood that DE9 is the future but reality is in the present with LE9 to get an old app running on Win11.

Managed to sort a solution for the above print issue without the need for OML Hide/Show.

Just another question that may be useful.

Is the SetState function Enable / Disable the same as 'Allow Entry' / 'Prevent Entry' ?

If so what is the correct syntax for SetState to do this?

Have tried SetState("FieldName", "Enable") ; SetState("FieldName", "3") and SetState("FieldName", 3)

There is a big difference between field name and object name. All GUI functions work on Object Names and is completed unrelated to the field (column). 

The problem is of course that when you rename a field it will not rename the object.

The message is not that you shouldn't move your old application to work, but simply that you should stop thinking that functions in a version 30 years old should just work the same 30 years later. There has been many iterations of DataEase since so the way forward is to find the best way to do it now rather than spend all the energy trying to do it the same way as before. 

You can most likely rebuild your forms much better faster than trying to get all the work arounds and hacks to work the same way now.

PS! Object Names are case sensitive too.

The example given is in a new application with Objectnames = fieldnames.

What is the answer to the question?

We are not sure we are following you, what is the question?

If a customer doesn't have a support agreement with us there is no rule that we should supply the solution to a problem the said customer is encountering in using DataEase for Development.

However we do answer questions that is of general interest. 

In this case the move from DE6 to DE9 has arisen a lot of sleeping dogs. 

We understand that it can be "convenient" if everything just stayed the same but from DE6 to DE9 there is over 20 years of development so it is more surprising if things are the same.

Our focus is on moving forward customers that has been following the upgrade path and insure they have as trouble free an experience as possible. Customers that has chosen to stay behind in older version for different reasons - DFD,DFW5, DFW6, DFW7 etc, have done so after doing a risk evaluation that might now come back to bite them.

Our development path is set, and LE9 is the version where DFW meet the future, and it is also the version that will be supported in the future for people that again choose to stay behind.

How people work with tools has also changed a lot since the days of DFD and DFW 5/6/7. Up to and including DE7.0 DataEase published printed manuals and supplied the software on physical media.

From then on everything has been online, with only documentation and online delivery.

We have written a lot about the new development in DataEase 8 and will do even more when DE9 is fully release. 

The focus will be on publishing a completely new functionality/function lexica and articles/blog on the new features with corresponding samples.

We will also open a new support forum for all customers that has paid maintenance on LE9/DE9, where they can ask a certain number of LE9/DE9 related (Product only, not application related) support questions. This forum will be read only for customers that doesn't pay maintenance.

We are also opening a new support/development centre where customers can sing both Product/Application support agreements online for a set amount of hours pro month/year.

But the main way of getting support will be for customers to find help/articles/blogs themselves online.

Most people that has worked with DE8 will be very familiar with the functions in the Set Library but we include a link to an article about this below.

https://www.dataease.com/DG3_BlogList/?ParentID=00...

hint: "Enable" maybe =1 in binary or 0 ; i depends what logic is ... in a chip low voltage means 1 whilehigh = 0 ;)

as to ASCII "3" =00110011

and 3 in binary = 0011

Ihor, we have discussed "hijacking" threads. 

Answers should only be helpful with the matter and not philosophical etc. This is SIMPLY a forum for solving things in DataEase!!

Agree fully but the question was as "Just another question that may be useful.

Is the SetState function Enable / Disable the same as 'Allow Entry' / 'Prevent Entry' ?

If so what is the correct syntax for SetState to do this?

Have tried SetState("FieldName", "Enable") ; SetState("FieldName", "3") and SetState("FieldName", 3) " and my hint may be will help to Dear Sam a bit.

as to philosophy then DataEase philosophy means WHAT TO DO BUT NOT HOW TO DO since 1980's

so our friend Sam will understand what I mean for sure

no hackings workarounds or hijacking in the case

simply the essence of the subject matter

Thx to DataEase team and to Ulric for Your great job.

the discussion helps me to waste the time while waiting for new LE9 release since 30/08/2024

Sorry for possible inconvenience ... very sorry

ALSO my hint was to DataEase team too not only to Dear Sam only

I meant the question ... in a polite form pointing through the functions mentioning in old good Britain style/mood ;) 

non explicit pointing out to avoid direct conflict of interests ;)

is it clear Gentlemen ? (The Posthumous Papers of the Pickwick Club)

To be honest, I'm not sure we follow.

It state clearly in the documentation that SetState work in OBJECT NAME and not FIELD NAME. It also state how to use it and that both "Disable", "2" and 2 works... 

This discussion is the evidence that people try to do things the wrong way for far to long before actually changing tack and questioning why it was done the way it was done 20 years ago and maybe when moving forward it would be better to think in a "modern" way, rather than hank back to the "dark ages" of DataEase at least constantly.

Personally I would have been able to make all this stuff from scratch in the same time it has taken for this discussion to unfold. 

Read the posts then it would be clear that for this example the ObjectName = the fieldname as is the default for any new field created.

So, yes, the ObjectName has been used as stated in the rather abbreviated 'documentation' for SetState which refers to options for 'Enable' / 'Disable'

What is not clear is whether Enable/Disable is the same as Allow Entry / Disable Entry?

As was also stated is that the function was tested with the following options and does not work to Allow entry

SetState("ObjectName", "Enable") ; SetState("ObjectName", "3") and SetState("ObjectName", 3)

Either this implies that Enable/Disable is not the same as Allow Entry/ Disable Entry or the function does not work in LE9