Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.

Data is not displayed

I used SRP EDitTable control version 3.0.9 (build date 10/21/15). The use has to hover the row so that they can see the data. This version has no SRP Controls.ocx.
Please help.
Thanks.

Comments

  • edited October 2016
    Check to see if you have another control on your form in the same spot as the SRP EditTable. If they are both in the same spot, they will fight each other to be the one on top. That would explain why nothing appears until the user hovers. If this does not describe your problem, please provide screenshots.

    Also, make sure you are only using SRPControls.ocx. You cannot use both SRPControls.ocx and SRPEditTable.ocx. That will cause all kinds of problems.
  • Hi Kevin,
    Thanks for your help.
    I had 2 SRP.EditTable.1 in the same form and it worked fine with version 2.2.7.
    Last week, I wanted to use Version 3 so that I can use the new control that Don developed for us.
    1. When I used SRPEditTable.ocx, the data is displayed but the dropdrown had no data.
    2. When I used SRPControls.ocx, the dropwdonw has data, but to row data is not displayed.
    I send the 2 print screens, SRPEditTable.ocx and SRPControls.ocx
    Thanks
  • This narrows things down. Am I to understand that the combo drop down is empty until you hover the mouse over it? Or does it stay empty until the user presses backspace?
  • I think we get it. This first time it was empty, but when I press backspace the data is populated.
    Why does combo drop down behave different with Version 2? How to fix it?
    I want to use SRPControls.ocx so I can drap and drop the email. How do we combine EditTable and controls.ocx?
    Thanks.
  • We added a feature to combo drop downs so that they shrink as you type. I think the problem is that you are defaulting the Tax Code to 0, but there isn't a 0 in the drop down. To turn the feature off, set field <2, 9> of the CellType property to 0.

    SRPControls.ocx contains all our controls. It has SRP EditTable inside of it. So, with just SRPControls.ocx, you can use SRP EditTable and SRP Tree (for the Outlook drag-n-drop).
  • set <2, 9> = 0 is fixed this issue.
    I think I need the SRP Tree. Right now Outlook drag-n-drop is not working.
    Thanks a lot for your help.
  • I think you are confused by a few things and we need to sort out some basics before we can really move forward. You have a pre-release version of SRPControls.ocx that we provided you to test the Outlook drag-n-drop feature. That file should be the only control you have registered on your computer. This will give you the latest release of all the controls you have licensed. If you have other OCX files such as SRPEditTable.ocx then you need to remove those from your environment. They are older versions and no longer supported. Do not remove SRPUtil.ocx, that is a special file used by the SRP Editor. To summarize: the ONLY .OCX files you should have that come from SRP are SRPControls.ocx and SRPUtil.ocx. If this confuses you then do not do anything or you might do more harm than good. Write back and let us know what is confusing.

    I think you know this, but just to make it clear, the Outlook drag-n-drop is only supported with the SRP Tree control.
  • but it will be supported by the picture control soon though right?

    https://forum.srpcs.com/discussion/95/drag-and-drop#latest


  • Mark - Sorry to pour cold water on your dreams, but that is not something you should expect soon. The SRP Tree control was picked for this project because it already had the technical framework needed for this type of drag-n-drop. The Picture control does not. Also, what we did is not the same as dragging attachments out of an email. We are dragging the entire email itself, with everything embedded. This ended up being a stupidly difficult project just to get this far. Pulling attachments out of the email is a completely new work altogether. Even if we get paid to do it, I'm not sure Kevin will be eager to dive into this mess again. :)
  • Mark - Just to confirm, your bigger need is to support drag-n-drop for the email attachments, not the email itself, correct? That was my understanding from the thread you linked to. Is the reason you want this to be handled by the SRP Picture control is so you can immediately display the image you are dragging onto it?
  • :)
    So far as emails are concerned, yes the drag-n-drop was to do with attachments.
    The thread was initiated by a request from a client to be able to drag images directly from a browser into OI.
    I had set up the picture control to enable the drag-n-drop from windows explorer but they found they were sourcing most of the images from the web anyway so why not do so directly? In many cases we were immediately displaying the image but it wasn't the priority, just kind of a bonus. So why the picture control? Because we had already implemented it to provide a drag-n-drop solution and we were only looking at expanding the source location options.

    As far as email attachments, that was just an extension of the idea as I considered other applications where I might be able to implement a similar drag-n-drop import solution.

    So the overall objective is how do users easily "import" windows files of any sort into an OI application without having to use the choosefile utility and browse to them? Email attachments are a potential source as is the browser or windows explorer.

    Here's a more recent example of where I've implemented that kind of solution. This one does not use the auto display. Indeed the picture control at the top of the window that the files are dropped into, doesn't display anything at all. It's just a bucket to catch things or a mailbox if you like. The big square on the right does all the displaying. This enables the user to just select a bunch of files within explorer and drag them into OI. The edittable below the mailbox immediately lists all the files dropped in so the user can add a more informative description than just the filename. As they move through the cells in the edittable the relevant file is displayed on the right so there's no doubt as to which file they are describing.



    Of course we don't actually save the file itself within OI but we do copy it to a predefined location and internally record the link.

    Does that make more sense of what I'm asking?
  • Mark - Yes this makes sense. I think where I wanted to go with this was simply pointing out that as far as creating a dedicated "drop zone" is concerned, it doesn't matter what control is used as long as it provides an obvious visual destination to drop your files onto. When the SRP Tree control is used as a drop zone, it looks very much like the SRP Picture control.

    I've done something similar to what you have done in your screen shot. However, the drop zone is only visible when the user triggers a desire to add files. I then hide much of the UI controls and display a large SRP Picture control. When the event is done, I hide the SRP Picture control and re-display the normal UI controls.

    The point being is that different implementations can require different solutions. I can see the value in your original request but I also see the SRP Tree control being useful more so than others might initially consider.
  • I think where I wanted to go with this was simply pointing out that as far as creating a dedicated "drop zone" is concerned, it doesn't matter what control is used as long as it provides an obvious visual destination to drop your files onto.
    Agreed and..... as long as it allows the user to drop from outside of OI. To date, only the picture control was able to do that and the tree control was limited to dragging only within or between tree controls. Moving forward if the tree control becomes able to provide the same and more functionality then it would be worth considering switching one out for the other.
    However, the drop zone is only visible when the user triggers a desire to add files.
    I assume similar to when inserting a file on this very forum.

    I also see the SRP Tree control being useful more so than others might initially consider
    Looking forward to considering the possibilities and then giving you and Kevin a few more grey hairs with some more "what ifs" and "is it possible"s.
  • Would you believe I got asked yesterday if we could drag emails into that window I've screenshot above?

    It's only just been put into production and it's the first question they've asked.

    So when's that new tree control coming? :)
  • Hello Don,
    Today I have some times to test your suggestion:
    1. The data is not displayed in the SRP edittable after I removed SRPEditTable.ocx, and registered SRPUtil.ocx and SRPControls.ocx. Would you tell me what else should I do?
    2. I want to drag the attached files (doc, excel, pdf, txt,...) from email. Do you have any document, sample codes?
    3. When do you send me the final release?
    Thanks.
Sign In or Register to comment.