Easy to Create, Easy to Change - Easy to use!


Copy & Paste doesn't work


Started by Marco Marchesi
Search
You will need to Sign In to be able to add or comment on the forum!

Copy & Paste doesn't work

Hi all, when I simply try to copy a value from whatever source (e.g. from txt) and paste the value into a table for searching a value inside, the value is not pasted and I force to enter the searched value manually. Why?

Written by Marco Marchesi 13/05/14 at 08:40:05 Dataease [{8}]FIVE

Application that Showcase how you can write-protect and search with paste in a Form.

Download Sample!


As you all point out, this worked in DFW up to 7.2 but not in 8.x. Most likely it worked in 8.0 but somewhere along the way this was "corrected".

We did a lot with copy/pasting in Memo fields so it might be related to that. It is of the list of fixes, but it is a long list and so far it has not reached the top.

However... Where the entire point with all previous versions of DFW was to "force" the users to upgrade through "fear" of incompatibility with new windows versions etc, the entire point of DE8 is to add functionality and improve the developer and ultimately the user experience of both developing and using a DE8 application.

Present company excepted (Simon, Marco and Stewart which I know are hard at work from early to late ;-), there has been a slightly "docile" approach to development in DataEase where the focus is on maintenance, stability and "keeping it running" rather than improving, new elopment and expanding the applications.

Here you have offered us a perfect opportunity to showcase how a problem can become an opportunity, where programming is a better and more flexible solution than "hardcoded" functionality.

I assume that you guys have made a new form on top of an existing table simply for searching?

I won't go into all the exciting ways of how that path can be explored and exploited, but I will emulate the functionality you have "lost".

In the attached sample we use SetState(), Custom Menu and Custom Toolbar to "force" the user to use our functionality correctly.

SetState() is made to cascade i.e. if you hide/disable etc. a group object (Form,Tab,Subform etc.) it will do the same to all the children.

So to disable the entire form you simply need to disable the main record (always called Record1 and is the first one in the object three).

We simply make a virtual field in the form that say:

SetState("Record1",2) 

Now you have disabled all fields and all button actions on the form including subforms etc.

You will still be able to search and crucially use PASTE to search.

In our sample we have done a little more, we have also re-enabled buttons that we want to use (Search) and given some messages.

SetState("Record1",2)+SetState("Search",3)+SetState("Manip",0)+SetStyle("Button1","Normal")+SetLabelText("Heading","Searchable (with paste) Read-only form")

The crucial change in mindset here is that when  you start "programming" you are in charge and are responsible, so you need to set and reset the functionality according to state etc. 

In DE8 you can get DE to do whatever you like, but you need to take responsibility and exploit standard functionality i.e. if you change it, don't expect to get it both ways ;-)

Since we haven't really disabled the form, just the controls the effect will not retain in Table view which isn't a Real DataEase form, so if you don't want the user to be able to save changes, delete etc, simply disable those features in the form altogether.

To be honest, it is something that should be done much more extensively in DE apps, as the default toolbars/menus give users a lot of frustration and confusion if they are there but don't work etc.




Simply delete the Menu entries and Short-Cuts for the functions you don't want and the user will not be able to do things they shouldn't.


DataEase default functionality should be kept on a minimum rather than a maximum which has been a tendency throughout DFW. Only the obviously beneficiary default functionalities should be "enforced", but even them need to be over-rideable. 

So much good functionality in DFW has been "wasted" because it was too restrictive or too inflexible. Functions should always only do one thing and a combination of functions the wanted functionality.

Also called: Programming.

Written by DataEase 20/03/15 at 09:10:50 Dataease [{8}]FIVE

Re:Application that Showcase how you can write-protect and search with paste in a Form.

It's a text field, it's searching for a piece of text in a text field.  I can type my search in a text field after choosing query start from menu/button/shortcut, why has the ability to paste a piece of text in a text field been removed??  How it worked worked, it weasn't a bug, an issue, a faulty piece of code, it worked as it should, how is this now 'corrected'???, it wasn't wrong to start with.

My order form has  asimple qbm so it only shows the last 12 months of orders.  My ARCHIVE form over the same table shows everything, i.e. no qbm, and is prevent entry, simple! took all of 30 seconds.  Nothing to do with memo's, it's a simple text field, or a number, or numeric, anything but memo.

I already do all that with the menu's but it's irrelivant to this issue.  Ticking ONE box to stop people changing anything is the whole point of having that box, i don't need to change filters to show everything on an existing form, fancy scripts to hide buttons saying save, changing menus etc etc. Copy form, prevent entry, done!

Disabling Paste/ctrl-v isn't correcting something, it's removing standard windows functionality.  I can type it the exact same field so how can pasting my letters in to it be a problem that had to be corrected?  It's a bug, and a big one.

Written by Simon B 20/03/15 at 10:36:17 Dataease [{8}]FIVE

Re:Copy

Is this on a user form where form insert/update has been disabled?

Written by Stewart Allen 13/05/14 at 18:40:57 Dataease [{8}]FIVE

Re:Re:Application that Showcase how you can write-protect and search with paste in a Form.

"We did a lot with copy/pasting in Memo fields so it might be related to that. It is of the list of fixes, but it is a long list and so far it has not reached the top."

I think that we in the sentence above go very far in admitting that it wasn't removed on purpose, and we try to pinpoint what we have done that could cause such a side effect.

The fact that your field is a text field is completely irrelevant as this is dealt with on a completely different level of the software. 

We admit that it is a bug, that it is registered and that it will eventually be fixed.I beg for understanding that we need to prioritise our resources, not the individual need of each user.

With danger of sounding flippant, we offer an extended trial period before anyone need to buy our software and one would assume that if any individual find the older software preferable that is what they should use.

We have radically updated and changed DFW in 8.0 to 8.5 and inadvertently that will cause some functionality to change or get broken.

We will fix it in due course if it is unintentional, or if we find out that it was detrimental but we need to keep to our development cycle and plans.

Lastly we want to add that this forum is about getting help and discuss ideas.

When we reply to a post it is not to help ONE individual but to offer ideas and inspiration for everyone, now and in the future, so we will use a post to showcase people that are interested how to use the product in different and new ways too.

If this was a personal conversation, we could just resort to mail so the answers will include stuff that is not necessarily what the original poster or commenter was looking for.

I realise that we might have spoilt our users because we are so quick to respond to requests on here, while we should maybe leave it to the community to respond. It takes a lot of time and effort to make samples and solutions, so we need to make sure that if/when we do it has general interest, rather than special interest.

Written by DataEase 20/03/15 at 11:01:22 Dataease [{8}]FIVE

Re:Re:Re:Application that Showcase how you can write-protect and search with paste in a Form.

It doesn't works even on your sample database if I set prevent-entry to ON using degroup version 8.2.0.1696 or higher. If I use degroup version 8.1.0.1464 it works anyway.

Written by Marco Marchesi 10/04/15 at 08:58:59 Dataease [{8}]FIVE

Re:Re:Re:Re:Application that Showcase how you can write-protect and search with paste in a Form.

The sample showcase how you can do it without setting Prevent-entry on. You do the write protect manually via SetState().

If you disable the Form with SetState() it will not be disabled when in Table View or when Being In Search View.

Written by DataEase 10/04/15 at 11:12:36 Dataease [{8}]FIVE

Re:Re:Re:Re:Re:Application that Showcase how you can write-protect and search with paste in a Form.

The example doesn't works anyway (using setstate in Manip field) . The copy and paste doesn't work also on dataease 8.5. In any case in not a valid method because if I check "Prevent data entry" some user could be enter the data in the table even if not authorized. Please solve.

Written by Marco Marchesi 04/04/16 at 12:47:14 Dataease [{8}]FIVE

Re:Re:Re:Re:Re:Re:Application that Showcase how you can write-protect and search with paste in a Form.

Any news about this problem?

Written by Marco Marchesi 13/07/16 at 07:07:10 Dataease [{8}]FIVE

Re:Re:Re:Re:Re:Re:Re:Application that Showcase how you can write-protect and search with paste in a Form.

Yes. Our team have been looking into it and it seems the bug is actually upside down.

The problem is that you can paste both in Query Mode and in Edit mode so the its not a bug that you can't past in Query mode it was a bug that you could in Edit mode.

So when the bug that you could paste in Edit Mode was fixed it was also "fixed" in Query Mode.

So far so good. We could now use the term "As designed...." ;-)

But.

You are of course right. There is no logical reason why you shouldn't be allowed to paste in Query mode even though it is most likely a rather novel approach so the team has it on its list but the fix is more far reaching than one could think as this is going back to the beginning of times. 

Written by DataEase 13/07/16 at 08:13:37 Dataease [{8}]FIVE

Re:Re:Re:Re:Re:Re:Re:Re:Application that Showcase how you can write-protect and search with paste in a Form.

OK. I'll wait a quick solution. Take in mind that I cannot install next versions of the product (included 8.5) until this problem is resolved.

Written by Marco Marchesi 13/07/16 at 08:26:41 Dataease [{8}]FIVE

Re:Re:Re:Re:Re:Re:Re:Re:Re:Application that Showcase how you can write-protect and search with paste in a Form.

Just out of curiosity... What do you use this for?

There is plenty of work around's for this in DataEase so why is this a showstopper?

This is a "non-existing" problem to 99.99999% of our user base so I hope you understand that we need to prioritise the bugs that involves the bigger number of users.

We are sorry that this stop you from moving forward but that would anyway be the way you should prioritise if the benefit of upgrading/moving forward is not estimated to be greater than staying.

We develop the product to make it better for the users but it is your job to decide if we get it right or not.

Written by DataEase 13/07/16 at 08:56:14 Dataease [{8}]FIVE

Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Application that Showcase how you can write-protect and search with paste in a Form.

OK. I understand. I decide from my side if it's useful for my company stay on the actual version or move forward  with the later versions. Anyway the last working version with Copy&Paste with prevent entry set to on is 8.1.0.1464 (obviously degroup version) and at the moment I force to stay on this version (consequently also with the developer version 8.2.0.1700) .From my point of view this feature will give the possibility to the users to filter any fields they want without create a specific form with a specific filter for this (like the old DFW version 6.52). Thanks.

Written by Marco Marchesi 13/07/16 at 09:10:21 Dataease [{8}]FIVE

Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Application that Showcase how you can write-protect and search with paste in a Form.

Just to confirm the facts here.

We have tested this in 6.x, 7.x etc.

The pasting only works when using the mouse and right click is that correct. The pasting does not work with Keyboard shortcuts?

If this is not correct, please let us know how you past into the fields where it works.

Written by DataEase 13/07/16 at 10:35:05 Dataease [{8}]FIVE

Re:Re:Copy

Yes the form insert/update has been disabled (see below) but the possibility of copy & paste (available since version 6.52 and lower) MUST BE MANTAINED. The copy and past works ONLY if I uncheck the "prevent data entry" !!! Most of my tables are born only for inquiry and I must have the possibility to select data from them using simply copy and paste. My database is a datawarehouse. Take in mind that we have a very large database with about 919 tables.!!!  Please find quickly a solution for this.

Written by Marco Marchesi 14/05/14 at 06:17:28 Dataease [{8}]FIVE

Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Application that Showcase how you can write-protect and search with paste in a Form.

The pasting (with prevent entry set to on) doesn't works anyway is that I use the mouse or via shortcut (CNTRL-V).

Written by Marco Marchesi 13/07/16 at 10:52:58 Dataease [{8}]FIVE

Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Application that Showcase how you can write-protect and search with paste in a Form.

I am sorry but this answer didn't make it any clearer....

1. We agree that this does not work in the new versions but as far as we can tell it only works when you use the mouse in older versions too. 6.52 and 7.2 etc.

2. Can you use CTRL-V in older versions as we cant.

Written by DataEase 13/07/16 at 11:30:45 Dataease [{8}]FIVE

Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Application that Showcase how you can write-protect and search with paste in a Form.

Ok we agree. The old version 6.52 and 7 the copy&paste works but we don't use them anymore. We migrated 2 years ago to version 8 and copy&paste worked up version 8.1.0.1464. In the later versions i tested this function and it doesn't works. I hope I was clear. Thanks for your attention to this topic.

Written by Marco Marchesi 13/07/16 at 11:54:59 Dataease [{8}]FIVE

Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Application that Showcase how you can write-protect and search with paste in a Form.

Almost...

We agree that it doesn't work at all now, but we can't get keyboard shortcut (CTRL-V) etc to work in any previous version either.

It does not work in 6.52 or 7.2 either.

But Mouse works in them and 8.0 and 8.1.

So the question was.

Does CTRL-V work with you? or do you need to use mouse?

Written by DataEase 13/07/16 at 12:08:07 Dataease [{8}]FIVE

Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Application that Showcase how you can write-protect and search with paste in a Form.

IT DOESN'T WORKS ANYWAY. If I use mouse it doesn't works. If I use CTRL-V it doesn't works. What I can do?

Written by Marco Marchesi 13/07/16 at 12:12:28 Dataease [{8}]FIVE

Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Re:Application that Showcase how you can write-protect and search with paste in a Form.

DOES IT WORK WITH KEYBOARD IN 8.1 AND BEFORE!!!! 

We already know that it works with Mouse but it doesn't work with keyboard in our test so we want to know if it works with KEYBOARD in 8.1 and before.

We don't try to convince you that it works in 8.5 as we know it doesnt!!

Written by DataEase 13/07/16 at 12:21:10 Dataease [{8}]FIVE

Copy/Paste in Query Mode fixed in 8.5.0.2424

In the reasarch of this bug we found that the same problem/limitation was present for LiveReports.

Strictly speaking LiveReports is designed to be exactly the same as a WriteProtected form and it was when our team was researching to check if this could be suggested as a temporary workaround for you that this was found.

As LiveReports and QBM are to be scrapped in future versions your solution is much more viable and really showcase that the features that QBM offers can really much better be entertained with FORM rather than QBM.

Some times crying and yelling a lot helps and it certainly did this time as the team by looking for the workaround also realised the underlying dynamics and hence could fix it.

The problem was really that a bug was fixed in 8.5 that closed the ability to past into a write protected form.

Obviously there is no good or logical reason why this should prevent pasting into the Query Mode but you would never have been able to do this ever if not for the bug.

However the Copy/Pasting in QueryMode was seriously restricted for the same reason as keyboard shortcuts were already blocked in all modes.

As a result we have now fully enabled copy/past in Query Mode.

I.e. both keyboard shortcuts and mouse is now working.

PS! The bad news is of course that this fix will only be available in versions after 8.5.0.2424 which is yet to be released.

Written by DataEase 16/07/16 at 06:41:08 Dataease [{8}]FIVE

Re:Copy/Paste in Query Mode fixed in 8.5.0.2424

Thanks.

when it becomes available this version?

Written by Marco Marchesi 26/07/16 at 10:09:57 Dataease [{8}]FIVE

Re:Re:Copy/Paste in Query Mode fixed in 8.5.0.2424

We are currently fixing deep rooted and ancient problems with positioning toolbars etc. 

When this is completed we plan to do a slip-stream release of 8.5 before we concentrate on the ultimate 8.5 release later this autumn.

Written by DataEase 26/07/16 at 11:19:07 Dataease [{8}]FIVE

Re:Re:Re:Copy

Form level "Prevent Entry" has always prevented paste on all DFW versions.

Copy should though work even if Form "Prevent Entry" is set.

Agree 100% that a fix is needed to allow paste when in Query mode.

- if all fields do not require user form entry then set all fields "Prevent Entry" - copy & paste then does work

if fields cannot be set as prevent entry then these are the options:

- use Query \ Selection filter

- Create additional virtual or indexed prevent entry 'copy' fields for all fields that require search parameter entry. Create a new form with these 'copy' fields.

Written by Stewart Allen 14/05/14 at 23:01:05 Dataease [{8}]FIVE

Re:Re:Re:Re:Copy

"Form level "Prevent Entry" has always prevented paste on all DFW versions."

Not sure what it is I do different, but I use Dataease 6.52 and 7.2 and can confirm I CAN paste to search in a form set to prevent entry:

Query > Select Records

This clears the form to allow me to enter my search.

CTRL-V (or right click > paste) on and field and up comes my pasted data. 

Query > Select Records

I know see record 1 of xxxx matching records.

My FORM is set to prevent entry, as like yourself it is purely for reference, in my case of archived orders.

Looking at your form properties, the only difference I can see is my form is not defined as 'Defines Table'.

Can't test it out on 8.x due to my demo expiring and within the re test window,

Written by Simon B 19/05/14 at 11:44:36 Dataease [{8}]FIVE

Re:Re:Re:Re:Re:Copy

For sure the problem is different. We always use the button with the question mark (select records) to filter data from a DE table.

  • 1)Using DataEase 8.1 on windows 7 and using the same field on the same table , my colleague Martella works instead on my workstation copy & past doesn’t works.
  • 2)For Both using windows server 2008 R2 (32bit) copy & paste doesn’t work. (using the same field on the same table)
  • 3)The information are stored into clipboard but are not pasted. (if I use e.g. Notepad or Microsoft Office the value are pasted correctly)
  • 4)All the clients working on Dataease 8.0 on windows 7 works fine (copy & paste works with the same field on the same table)
  • 5)If I use the same table and the same field on 6.52 version it works fine.
  • 6)The fields doesn’t have “prevent entry” but the table MUST HAVE “Prevent entry” (I cannot remove it).
  • There’s perhaps something to change into dataease parameter or in the related system? Where?
  • This is very frustrating for us because we often use Copy and paste in order to select quickly information for different tables inside dataease.
  • I remember you that we have more than 900 tables only inside 1 database and is not acceptable to modify the table option for this.
  • Thanks a lot for your support.
  • Note : The table is with Prevent Entry and the field is without Prevent Entry 
Written by Marco Marchesi 11/06/14 at 12:51:34 Dataease [{8}]FIVE

Re:Re:Re:Re:Re:Re:Copy

I'm sorry. Have you find any valid solution for this problem? It's very important for me use copy&paste in Dataease. Please read carefully my previous comment. Thanks

Written by Marco Marchesi 02/07/14 at 12:24:04 Dataease [{8}]FIVE

Re:Re:Re:Re:Re:Re:Re:Copy

Just an update on this topic. Copy & Past work well on DataEase 7.2 but it doesn't work on DataEase 8.0 and higher. I remember you that I must to be use it on tables with prevent-entry ON and I cannot change it. To use Selection filter alternatively is not so fast or easy.

Written by Marco Marchesi 19/02/15 at 11:19:34 Dataease [{8}]FIVE

Re:Re:Re:Re:Re:Re:Re:Re:Copy

Just an update on this topic. Copy and paste on tables with prevent-entry on, doesn't work on degroup version 8.2.0.1696.

Written by Marco Marchesi 10/03/15 at 13:28:41 Dataease [{8}]FIVE

Re:Re:Re:Re:Re:Re:Re:Re:Re:Copy

+1 from  me.  Paste ALWAYS work in a prevent data entry FORM when doing a search, in dataease 6.52 and 7.2.   Now i've upgraded to 8.x (8.2.0.1700), I can TYPE what i want to search but longer PASTE what I want to search.  Used to be able to copy and paste data from an email to search for an order number, now i'm expected to remember and type in a 12 digit order number every time.  Rather annoying being allowed to search for typed workd but no longer being allowed to search for pasted words!

Written by Simon B 19/03/15 at 12:31:35 Dataease [{8}]FIVE