Skip to main content

Uniface Deployment: Discussion about Unifield and Edit Box functionalities

  • November 19, 2018
  • 10 replies
  • 0 views
Jan Cees Boogaard

Discussion about Unifield and Edit Box functionalities

Author: adrian.gosbell@synapse-i.jp (Adrian Gosbell)

About the whole unifield topic, these are still in the product solely for legacy purposes. We have a lot of old apps out there that still use them, and in the case of character mod (CHUI), it's the only option. The Uniface 9 developer would be a good example of a legacy Uniface app.   From a Uniface perspective, we advise to use the editbox rather than the unifield. We've implemented a lot of enhancements over the years into the editbox, we've consciously not done this with the unifield because we don't get all of the Windows libraries to build against, and we don't want to break anything (CHIU apps tend to be the most mission critical apps in the Uniface world).  As a brief history lesson, the unifield is completely Uniface proprietary, built by us pretty well from the ground up because 'back in the day', we had GUI's like Mac, OS/2, Motif, CHIU, Windows 3.1, and we needed to deliver GUI controls which were consistent across all of them (the name Uniface came from Universal Interface). The industry, and Uniface has moved on, the decision was made in the Uniface 8 era to solely focus on the Windows GUI (CHIU is still there, and in the case of the Mac, we had no choice).   As far as I am aware, the only unifield functionality that is not available in the editbox is the handling of the bold, italic and underline attributes on stored data, last time we looked into that, we couldn't find a realistic way to come up with an editbox alternative.  if there are other functional reasons not to use the editbox I'd like to know so we can see if we can do something about that. 

10 replies

Jan Cees Boogaard

Discussion about Unifield and Edit Box functionalities

Author: adrian.gosbell@synapse-i.jp (Adrian Gosbell)

About the whole unifield topic, these are still in the product solely for legacy purposes. We have a lot of old apps out there that still use them, and in the case of character mod (CHUI), it's the only option. The Uniface 9 developer would be a good example of a legacy Uniface app.   From a Uniface perspective, we advise to use the editbox rather than the unifield. We've implemented a lot of enhancements over the years into the editbox, we've consciously not done this with the unifield because we don't get all of the Windows libraries to build against, and we don't want to break anything (CHIU apps tend to be the most mission critical apps in the Uniface world).  As a brief history lesson, the unifield is completely Uniface proprietary, built by us pretty well from the ground up because 'back in the day', we had GUI's like Mac, OS/2, Motif, CHIU, Windows 3.1, and we needed to deliver GUI controls which were consistent across all of them (the name Uniface came from Universal Interface). The industry, and Uniface has moved on, the decision was made in the Uniface 8 era to solely focus on the Windows GUI (CHIU is still there, and in the case of the Mac, we had no choice).   As far as I am aware, the only unifield functionality that is not available in the editbox is the handling of the bold, italic and underline attributes on stored data, last time we looked into that, we couldn't find a realistic way to come up with an editbox alternative.  if there are other functional reasons not to use the editbox I'd like to know so we can see if we can do something about that. 

Hi Adrian, unfortunately, there are a couple of functionalities ONLY available with unifields: $char in the Start Modification, $curline, $curword ... still not quite sure if editboxes support the complete $keyboard options and all the structure editor macros. Let me give you an example: Decades ago, we built an accellerator to enter a date via unifield. We used a permenent SMOD invocation and evaluated $char: "w"/"W": add/subtract a week "m"/"M": a month "q"/"Q": a quarter "+"/"-": .. a day So if one wants to enter a delivery date "in 3 weeks", it took only 3 "w". Think it's still in use.


Author: ulrich-merkel (ulrichmerkel@web.de)
Jan Cees Boogaard

Discussion about Unifield and Edit Box functionalities

Author: adrian.gosbell@synapse-i.jp (Adrian Gosbell)

About the whole unifield topic, these are still in the product solely for legacy purposes. We have a lot of old apps out there that still use them, and in the case of character mod (CHUI), it's the only option. The Uniface 9 developer would be a good example of a legacy Uniface app.   From a Uniface perspective, we advise to use the editbox rather than the unifield. We've implemented a lot of enhancements over the years into the editbox, we've consciously not done this with the unifield because we don't get all of the Windows libraries to build against, and we don't want to break anything (CHIU apps tend to be the most mission critical apps in the Uniface world).  As a brief history lesson, the unifield is completely Uniface proprietary, built by us pretty well from the ground up because 'back in the day', we had GUI's like Mac, OS/2, Motif, CHIU, Windows 3.1, and we needed to deliver GUI controls which were consistent across all of them (the name Uniface came from Universal Interface). The industry, and Uniface has moved on, the decision was made in the Uniface 8 era to solely focus on the Windows GUI (CHIU is still there, and in the case of the Mac, we had no choice).   As far as I am aware, the only unifield functionality that is not available in the editbox is the handling of the bold, italic and underline attributes on stored data, last time we looked into that, we couldn't find a realistic way to come up with an editbox alternative.  if there are other functional reasons not to use the editbox I'd like to know so we can see if we can do something about that. 

ulrich-merkel said Let me give you an example: Decades ago, we built an accellerator to enter a date via unifield. We used a permenent SMOD invocation and evaluated $char: "w"/"W": add/subtract a week "m"/"M": a month "q"/"Q": a quarter "+"/"-": .. a day So if one wants to enter a delivery date "in 3 weeks", it took only 3 "w". Think it's still in use.

It should be possible to replicate this functionality nowadays with the onEdit (Extended) Trigger. It, however, is correct that most Structure Editor Functions for text navigation and editing will only work in Unifields (for details see here). It probably is possible to replace some of these functions with Windows API calls, but this is not really a "native" solution (although in some cases certainly viable). Daniel


Author: diseli (daniel.iseli@uniface.com)
Jan Cees Boogaard

Discussion about Unifield and Edit Box functionalities

Author: adrian.gosbell@synapse-i.jp (Adrian Gosbell)

About the whole unifield topic, these are still in the product solely for legacy purposes. We have a lot of old apps out there that still use them, and in the case of character mod (CHUI), it's the only option. The Uniface 9 developer would be a good example of a legacy Uniface app.   From a Uniface perspective, we advise to use the editbox rather than the unifield. We've implemented a lot of enhancements over the years into the editbox, we've consciously not done this with the unifield because we don't get all of the Windows libraries to build against, and we don't want to break anything (CHIU apps tend to be the most mission critical apps in the Uniface world).  As a brief history lesson, the unifield is completely Uniface proprietary, built by us pretty well from the ground up because 'back in the day', we had GUI's like Mac, OS/2, Motif, CHIU, Windows 3.1, and we needed to deliver GUI controls which were consistent across all of them (the name Uniface came from Universal Interface). The industry, and Uniface has moved on, the decision was made in the Uniface 8 era to solely focus on the Windows GUI (CHIU is still there, and in the case of the Mac, we had no choice).   As far as I am aware, the only unifield functionality that is not available in the editbox is the handling of the bold, italic and underline attributes on stored data, last time we looked into that, we couldn't find a realistic way to come up with an editbox alternative.  if there are other functional reasons not to use the editbox I'd like to know so we can see if we can do something about that. 

diseli said
ulrich-merkel said Let me give you an example: Decades ago, we built an accellerator to enter a date via unifield. We used a permenent SMOD invocation and evaluated $char: "w"/"W": add/subtract a week "m"/"M": a month "q"/"Q": a quarter "+"/"-": .. a day So if one wants to enter a delivery date "in 3 weeks", it took only 3 "w". Think it's still in use.
It should be possible to replicate this functionality nowadays with the onEdit (Extended) Trigger. It, however, is correct that most Structure Editor Functions for text navigation and editing will only work in Unifields (for details see here). It probably is possible to replace some of these functions with Windows API calls, but this is not really a "native" solution (although in some cases certainly viable). Daniel

we should also add the old 'scripting capability' which is tightly coupled to the structure editor and the old(er) widgets. That is an area we're probably not going to open up. Better tools for there for that nowadays.. 


Author: Adrian Gosbell (adrian.gosbell@synapse-i.jp)
Jan Cees Boogaard

Discussion about Unifield and Edit Box functionalities

Author: adrian.gosbell@synapse-i.jp (Adrian Gosbell)

About the whole unifield topic, these are still in the product solely for legacy purposes. We have a lot of old apps out there that still use them, and in the case of character mod (CHUI), it's the only option. The Uniface 9 developer would be a good example of a legacy Uniface app.   From a Uniface perspective, we advise to use the editbox rather than the unifield. We've implemented a lot of enhancements over the years into the editbox, we've consciously not done this with the unifield because we don't get all of the Windows libraries to build against, and we don't want to break anything (CHIU apps tend to be the most mission critical apps in the Uniface world).  As a brief history lesson, the unifield is completely Uniface proprietary, built by us pretty well from the ground up because 'back in the day', we had GUI's like Mac, OS/2, Motif, CHIU, Windows 3.1, and we needed to deliver GUI controls which were consistent across all of them (the name Uniface came from Universal Interface). The industry, and Uniface has moved on, the decision was made in the Uniface 8 era to solely focus on the Windows GUI (CHIU is still there, and in the case of the Mac, we had no choice).   As far as I am aware, the only unifield functionality that is not available in the editbox is the handling of the bold, italic and underline attributes on stored data, last time we looked into that, we couldn't find a realistic way to come up with an editbox alternative.  if there are other functional reasons not to use the editbox I'd like to know so we can see if we can do something about that. 

diseli said It should be possible to replicate this functionality nowadays with the onEdit (Extended) Trigger. Daniel

Unfortunately, the onEdit is not an onKeypressed but fires only after some typing inactivity. So it does not provide key by key in $char and therefore we do not know what is typed. But if you like: just implement the date-entry-accelleration. The SMOD trigger reads as: call SMOD_FASTDATE   entry SMOD_FASTDATE variables    string op    string char2op    string v_key endvariables char2op = "" ; setting operations lowercase = ADD period Uppercase = SUBTRACT Period ; for German: H=NOW T=day W=week M=month J=year S=hour N=minute C=Second ;char2op= "72=NOW104=NOW84=D-116=D+87=W-119=W+77=M-109=M+74=Y-106=Y+" ;char2op= "%%char2op%%%83=H-115=H+78=N+110=N+67=S-99=S+" ;getitem/id op,char2op,$char ;definition of the DATE-Part; comment out on TIME fields char2op= "H=NOWh=NOWT=D-t=D+W=W-w=W+M=M-m=M+J=Y-j=Y+" ;definition of the TIME-Part; comment out on DATE-fields ;char2op= "%%char2op%%%S=H-s=H+N=N+n=N+C=S-c=S+" ;or if not afraid of using undocumented features (shown on $UUU on the WEB): v_key = $tometa($char) getitem/id/case op,char2op,v_key if (op = "")    return(0) endif if (op = "NOW")    @$fieldname = $datim elseif (op = "D+")    @$fieldname = @$fieldname + 1d elseif (op = "D-")    @$fieldname = @$fieldname - 1d elseif (op = "W+")    @$fieldname = @$fieldname + 7d elseif (op = "W-")    @$fieldname = @$fieldname - 7d elseif (op = "M+")    addmonths 1,@$fieldname    @$fieldname = $result elseif (op = "M-")    addmonths -1,@$fieldname    @$fieldname = $result elseif (op = "Y+")    addmonths 12,@$fieldname    @$fieldname = $result elseif (op = "Y-")    addmonths -12,@$fieldname    @$fieldname = $result elseif (op = "H+")    @$fieldname = @$fieldname + 1h elseif (op = "H-")    @$fieldname = @$fieldname - 1h elseif (op = "N+")    @$fieldname = @$fieldname + 1n elseif (op = "N-")    @$fieldname = @$fieldname - 1n elseif (op = "S+")    @$fieldname = @$fieldname + 1s elseif (op = "S-")    @$fieldname = @$fieldname - 1s endif $prompt = $fieldname return (99) end ; SMOD_FASTDATE


Author: ulrich-merkel (ulrichmerkel@web.de)
Jan Cees Boogaard

Discussion about Unifield and Edit Box functionalities

Author: adrian.gosbell@synapse-i.jp (Adrian Gosbell)

About the whole unifield topic, these are still in the product solely for legacy purposes. We have a lot of old apps out there that still use them, and in the case of character mod (CHUI), it's the only option. The Uniface 9 developer would be a good example of a legacy Uniface app.   From a Uniface perspective, we advise to use the editbox rather than the unifield. We've implemented a lot of enhancements over the years into the editbox, we've consciously not done this with the unifield because we don't get all of the Windows libraries to build against, and we don't want to break anything (CHIU apps tend to be the most mission critical apps in the Uniface world).  As a brief history lesson, the unifield is completely Uniface proprietary, built by us pretty well from the ground up because 'back in the day', we had GUI's like Mac, OS/2, Motif, CHIU, Windows 3.1, and we needed to deliver GUI controls which were consistent across all of them (the name Uniface came from Universal Interface). The industry, and Uniface has moved on, the decision was made in the Uniface 8 era to solely focus on the Windows GUI (CHIU is still there, and in the case of the Mac, we had no choice).   As far as I am aware, the only unifield functionality that is not available in the editbox is the handling of the bold, italic and underline attributes on stored data, last time we looked into that, we couldn't find a realistic way to come up with an editbox alternative.  if there are other functional reasons not to use the editbox I'd like to know so we can see if we can do something about that. 

I've copied the above posts from the topic "[SOLVED] Unifield Inverse" since they were a bit off-topic.


Author: diseli (daniel.iseli@uniface.com)
Jan Cees Boogaard

Discussion about Unifield and Edit Box functionalities

Author: adrian.gosbell@synapse-i.jp (Adrian Gosbell)

About the whole unifield topic, these are still in the product solely for legacy purposes. We have a lot of old apps out there that still use them, and in the case of character mod (CHUI), it's the only option. The Uniface 9 developer would be a good example of a legacy Uniface app.   From a Uniface perspective, we advise to use the editbox rather than the unifield. We've implemented a lot of enhancements over the years into the editbox, we've consciously not done this with the unifield because we don't get all of the Windows libraries to build against, and we don't want to break anything (CHIU apps tend to be the most mission critical apps in the Uniface world).  As a brief history lesson, the unifield is completely Uniface proprietary, built by us pretty well from the ground up because 'back in the day', we had GUI's like Mac, OS/2, Motif, CHIU, Windows 3.1, and we needed to deliver GUI controls which were consistent across all of them (the name Uniface came from Universal Interface). The industry, and Uniface has moved on, the decision was made in the Uniface 8 era to solely focus on the Windows GUI (CHIU is still there, and in the case of the Mac, we had no choice).   As far as I am aware, the only unifield functionality that is not available in the editbox is the handling of the bold, italic and underline attributes on stored data, last time we looked into that, we couldn't find a realistic way to come up with an editbox alternative.  if there are other functional reasons not to use the editbox I'd like to know so we can see if we can do something about that. 

ulrich-merkel said Unfortunately, the onEdit is not an onKeypressed but fires only after some typing inactivity. So it does not provide key by key in $char and therefore we do not know what is typed.

It's correct that by default there's a delay (that will cause the trigger to be fired after an inactivity of 200 ms). But the delay can be disabled when setting the EditDelay property to False. And then the onEdit trigger is fired each time the user changes the content of the field. It's also correct that $char is not available, but you have the complete field content to work with.


Author: diseli (daniel.iseli@uniface.com)
Jan Cees Boogaard

Discussion about Unifield and Edit Box functionalities

Author: adrian.gosbell@synapse-i.jp (Adrian Gosbell)

About the whole unifield topic, these are still in the product solely for legacy purposes. We have a lot of old apps out there that still use them, and in the case of character mod (CHUI), it's the only option. The Uniface 9 developer would be a good example of a legacy Uniface app.   From a Uniface perspective, we advise to use the editbox rather than the unifield. We've implemented a lot of enhancements over the years into the editbox, we've consciously not done this with the unifield because we don't get all of the Windows libraries to build against, and we don't want to break anything (CHIU apps tend to be the most mission critical apps in the Uniface world).  As a brief history lesson, the unifield is completely Uniface proprietary, built by us pretty well from the ground up because 'back in the day', we had GUI's like Mac, OS/2, Motif, CHIU, Windows 3.1, and we needed to deliver GUI controls which were consistent across all of them (the name Uniface came from Universal Interface). The industry, and Uniface has moved on, the decision was made in the Uniface 8 era to solely focus on the Windows GUI (CHIU is still there, and in the case of the Mac, we had no choice).   As far as I am aware, the only unifield functionality that is not available in the editbox is the handling of the bold, italic and underline attributes on stored data, last time we looked into that, we couldn't find a realistic way to come up with an editbox alternative.  if there are other functional reasons not to use the editbox I'd like to know so we can see if we can do something about that. 

"It should be possible to replicate this functionality nowadays with the onEdit (Extended) Trigger" @diseli: So proof implementing the entry SMOD_FASTDATE without $char, I'm interested to learn new concepts.


Author: ulrich-merkel (ulrichmerkel@web.de)
Jan Cees Boogaard

Discussion about Unifield and Edit Box functionalities

Author: adrian.gosbell@synapse-i.jp (Adrian Gosbell)

About the whole unifield topic, these are still in the product solely for legacy purposes. We have a lot of old apps out there that still use them, and in the case of character mod (CHUI), it's the only option. The Uniface 9 developer would be a good example of a legacy Uniface app.   From a Uniface perspective, we advise to use the editbox rather than the unifield. We've implemented a lot of enhancements over the years into the editbox, we've consciously not done this with the unifield because we don't get all of the Windows libraries to build against, and we don't want to break anything (CHIU apps tend to be the most mission critical apps in the Uniface world).  As a brief history lesson, the unifield is completely Uniface proprietary, built by us pretty well from the ground up because 'back in the day', we had GUI's like Mac, OS/2, Motif, CHIU, Windows 3.1, and we needed to deliver GUI controls which were consistent across all of them (the name Uniface came from Universal Interface). The industry, and Uniface has moved on, the decision was made in the Uniface 8 era to solely focus on the Windows GUI (CHIU is still there, and in the case of the Mac, we had no choice).   As far as I am aware, the only unifield functionality that is not available in the editbox is the handling of the bold, italic and underline attributes on stored data, last time we looked into that, we couldn't find a realistic way to come up with an editbox alternative.  if there are other functional reasons not to use the editbox I'd like to know so we can see if we can do something about that. 

ulrich-merkel said @diseli: So proof implementing the entry SMOD_FASTDATE without $char, I'm interested to learn new concepts.

This is just a POC, but it seems to do the trick. And yes, it's not as "clean" and "simple" as with $char. UPDATE [15-Mar-2016]: this is the 'tweaked' version mentioned in my reply below.

; Start Modification ; The Struct component variable $CMP_PROPERTIES$ is initalized in the Exec trigger $CMP_PROPERTIES$->FASTDATE2->$scalar = @$fieldname $CMP_PROPERTIES$->FASTDATE2->$tags->FORMATTED = "%%@$fieldname" $CMP_PROPERTIES$->FASTDATE2->$tags->SMOD = 99
; Extended Trigger trigger OnEdit   variables   string vContentNew, vContentOld   numeric i endvariables if ($CMP_PROPERTIES$->FASTDATE2->$tags->SMOD = 99)   $CMP_PROPERTIES$->FASTDATE2->$tags->SMOD = 0   vContentOld = $CMP_PROPERTIES$->FASTDATE2->$tags->FORMATTED   vContentNew = @$fieldname   for i = 1 to $length(vContentNew)     if (vContentNew[i:1] != vContentOld[i:1])       $CMP_PROPERTIES$->FASTDATE2->$tags->SMOD = SMOD_FASTDATE2($CMP_PROPERTIES$->FASTDATE2->$scalar, vContentNew[i:1])       break     endif   endfor   $CMP_PROPERTIES$->FASTDATE2->$scalar = @$fieldname   $CMP_PROPERTIES$->FASTDATE2->$tags->FORMATTED = "%%@$fieldname" endif end ; trigger onEdit 
entry SMOD_FASTDATE2 params   datetime vContentOld : IN   string v_key : IN endparams variables   string op   string char2op endvariables char2op = "" ; setting operations lowercase = ADD period Uppercase = SUBTRACT Period ; for German: H=NOW T=day W=week M=month J=year S=hour N=minute C=Second ;char2op= "72=NOW104=NOW84=D-116=D+87=W-119=W+77=M-109=M+74=Y-106=Y+" ;char2op= "%%char2op%%%83=H-115=H+78=N+110=N+67=S-99=S+" ;getitem/id op,char2op,$char ;definition of the DATE-Part; comment out on TIME fields char2op= "H=NOW·;h=NOW·;T=D-·;t=D+·;W=W-·;w=W+·;M=M-·;m=M+·;J=Y-·;j=Y+" ;definition of the TIME-Part; comment out on DATE-fields ;char2op= "%%char2op%%%S=H-s=H+N=N+n=N+C=S-c=S+" getitem/id/case op,char2op,v_key if (op = "")   return(0) endif if (op = "NOW")   @$fieldname = $datim elseif (op = "D+")   @$fieldname = vContentOld + 1d elseif (op = "D-")   @$fieldname = vContentOld - 1d elseif (op = "W+")   @$fieldname = vContentOld + 7d elseif (op = "W-")   @$fieldname = vContentOld - 7d elseif (op = "M+")   addmonths 1,vContentOld   @$fieldname = $result elseif (op = "M-")   addmonths -1,vContentOld   @$fieldname = $result elseif (op = "Y+")   addmonths 12,vContentOld   @$fieldname = $result elseif (op = "Y-")   addmonths -12,vContentOld   @$fieldname = $result elseif (op = "H+")   @$fieldname = vContentOld + 1h elseif (op = "H-")   @$fieldname = vContentOld - 1h elseif (op = "N+")   @$fieldname = vContentOld + 1n elseif (op = "N-")   @$fieldname = vContentOld - 1n elseif (op = "S+")   @$fieldname = vContentOld + 1s elseif (op = "S-")   @$fieldname = vContentOld - 1s endif end ; SMOD_FASTDATE

Author: diseli (daniel.iseli@uniface.com)
Jan Cees Boogaard

Discussion about Unifield and Edit Box functionalities

Author: adrian.gosbell@synapse-i.jp (Adrian Gosbell)

About the whole unifield topic, these are still in the product solely for legacy purposes. We have a lot of old apps out there that still use them, and in the case of character mod (CHUI), it's the only option. The Uniface 9 developer would be a good example of a legacy Uniface app.   From a Uniface perspective, we advise to use the editbox rather than the unifield. We've implemented a lot of enhancements over the years into the editbox, we've consciously not done this with the unifield because we don't get all of the Windows libraries to build against, and we don't want to break anything (CHIU apps tend to be the most mission critical apps in the Uniface world).  As a brief history lesson, the unifield is completely Uniface proprietary, built by us pretty well from the ground up because 'back in the day', we had GUI's like Mac, OS/2, Motif, CHIU, Windows 3.1, and we needed to deliver GUI controls which were consistent across all of them (the name Uniface came from Universal Interface). The industry, and Uniface has moved on, the decision was made in the Uniface 8 era to solely focus on the Windows GUI (CHIU is still there, and in the case of the Mac, we had no choice).   As far as I am aware, the only unifield functionality that is not available in the editbox is the handling of the bold, italic and underline attributes on stored data, last time we looked into that, we couldn't find a realistic way to come up with an editbox alternative.  if there are other functional reasons not to use the editbox I'd like to know so we can see if we can do something about that. 

diseli: your attempt to guess the causing keystroke by comparing before and after image of field contents fails when user actioned a delete, cut or paste. The best way would be to hook into the "keyboard queue" to feed this variable and provide some overall "beforeKeyPressed"/"afterKeyPressed" trigger. AFAIK, this can only be done by "the Lab".


Author: ulrich-merkel (ulrichmerkel@web.de)
Jan Cees Boogaard

Discussion about Unifield and Edit Box functionalities

Author: adrian.gosbell@synapse-i.jp (Adrian Gosbell)

About the whole unifield topic, these are still in the product solely for legacy purposes. We have a lot of old apps out there that still use them, and in the case of character mod (CHUI), it's the only option. The Uniface 9 developer would be a good example of a legacy Uniface app.   From a Uniface perspective, we advise to use the editbox rather than the unifield. We've implemented a lot of enhancements over the years into the editbox, we've consciously not done this with the unifield because we don't get all of the Windows libraries to build against, and we don't want to break anything (CHIU apps tend to be the most mission critical apps in the Uniface world).  As a brief history lesson, the unifield is completely Uniface proprietary, built by us pretty well from the ground up because 'back in the day', we had GUI's like Mac, OS/2, Motif, CHIU, Windows 3.1, and we needed to deliver GUI controls which were consistent across all of them (the name Uniface came from Universal Interface). The industry, and Uniface has moved on, the decision was made in the Uniface 8 era to solely focus on the Windows GUI (CHIU is still there, and in the case of the Mac, we had no choice).   As far as I am aware, the only unifield functionality that is not available in the editbox is the handling of the bold, italic and underline attributes on stored data, last time we looked into that, we couldn't find a realistic way to come up with an editbox alternative.  if there are other functional reasons not to use the editbox I'd like to know so we can see if we can do something about that. 

As said, it's just a POC. I've noticed that I've forgotten to emulate the '$status = 99' return value of the Unifield in the SMOD. After tweaking the code the onEdit routine seems to cover the majority of the functionality required here. I agree that there could be a problem when pasting data into the field, but delete or cut should have the same affect as in the Unifield (as far as I can see). And if this is not sufficient enough then one can still use a Unifield. And in case one would like more control over the entered data then the HTML widget might also be an attempt at a solution (by implementing the SMOD routine in JavaScript).


Author: diseli (daniel.iseli@uniface.com)

Recent badge winners

Explore all badges
Terms & ConditionsAccessibility statement