Getting Drag and Drop to work with a early version of Frameworks

JimPeters

I'm trying to use DND as a user friendly way for users to place edittable rows in the order that they want them. I tried the OI sample TEST_EDITTABLE_DND window on my 9.40 system, and it works as expected. So, using it as an example, I tried to get it to work on a simple window in my application that just has a simple OI edittable and a skeletal SRP style commuter module. Per the example and documentation, I enabled the 3 raw style bits on the OI edittable control, hoping to be able to catch some events starting with "DRAG" in my commuter module. I didn't set anything in Quick Events, and I am using Windows 10, BTW.

Instead of just passing the "DRAG" events to my commuter module as I had hoped, OpenInsight immediately crashes the moment I attempt to initiate any kind of Drag operation on the edittable. I suspect something is missing, possibly involving that "prototyping" word that I don't use often enough to stay proficient.

This version of Frameworks obviously pre-dates DND on OpenInsight as I see no references to it. Is there anything I should know about Drag and Drop with early versions of Frameworks? I'm guessing later versions have support and probably promoted DRAG events, so I'm thinking there is some knowledge I can tap into.

Thanks!
Jim Peters

DonBakke

Hi Jim,

The version and age of your FrameWorks system is not likely to be relevant. I was able to get the TEST_EDITTABLE_DND form to work while in a FrameWorks app. However...the commuter module did crash because FrameWorks assumes that the arguments in the commuter will be in a certain order and of a certain number.

So, is the commuter module you are using for your simple window based on TEST_EDITTABLE_DND_EVENTS or is it based on a known working commuter module from your application? I'm trying to rule out that perhaps OI is unhappy because you are trying to call a commuter with too many arguments.

JimPeters

Hi Don,

In the app I was using a very skeletal Frameworks commuter module on a simple dialog window type form with an OI editable and a couple of buttons on it. It worked fine until I enabled the 3 raw style bits for the edittable per the OI documentation. With that change, only, OI crashes if i click on the upper left corner of the edittable and attempt a drag. Clicking and dragging anywhere else doesn't seem to do anything.

Now, with the OI sample form, my PROMOTED_EVENTS procedure has an exclusion, and it runs as it should using their RTI style commuter module with 8 params. (The example has a quick event set to fire the commuter by name. )

Then, I tried using SRP Form Copy to make a copy of TEST_EDITTABLE_DND in my application, and ran into the error from the wrong number of parameters being passed to the OI Style commuter module, which is understandable. Adding parameters through 15 to the commuter and making sure they are null if unassigned clears the error, but it still crashes OI apparently before ever making it to the commuter if you try to do a drag.

I am having to think hard how to debug this!

Jim

DonBakke

Jim,

I'll try to match your effort and make a FrameWorks version of TEST_EDITTABLE_DND and see if it crashes. One thing you might try right away is to see if the PROMOTED_CREATE_EVENT code is contributing to the problem. I would write some quick code to exclude the window from that promoted event, but allow other promoted events to work. Since this Drag-N-Drop stuff involves style bit changes, special properties, and special messages, it would not surprise me if something in the standard CREATE setup is in conflict.

DonBakke

Jim,

Well, other than having to comment out the TEST_EDITTABLE_DND_EVENTS entry in the SYSENV\SYSPROCNAMES configuration record (I have no idea why they would protect this code), it was pretty easy to copy this into a local FrameWorks app and get it to completely run through the FrameWorks system.

It ran without any hiccups. So, this begs the question: what is different between your system and my system? I will gain suggest that you start isolating specific promoted event handlers (starting with the CREATE event) and then see how it goes.

JimPeters

Thanks, that is helpful to know. I will try excluding it from promoted event handlers as you suggest and take a close look at the CREATE.

This is actually the first time I felt the urge to use drag and drop in this application. There are other ways to get the job done and i could fall back on them if this is too problematic. But it is hard to pass up a challenging problem without gaining an understanding and solving it! And this is a worthy puzzle. ;-)

Looking at Event Designer, "Enforce" is set to "Yes" for the 4 DRAG events listed for edittables. Is this as it should be? I am suspicious that something is being done twice.

DonBakke

Jim,

Yep...I get the thrill of the challenge. It's kept me away from much more productive work far too many times. :)

That said, I've never been too fond of the Drag-n-Drop implementation of OI, so I've never used it. I wish our own EditTable control supported this, but we have found more use for Drag-n-Drop with the SRP Tree and SRP Picture controls.

The rule of thumb is that "Enforce" should be set in order for a given event handler to be promoted. Now, as you said, your version of FrameWorks is a bit old. So, what I don't recall is whether you have a version that implemented the application level promoted event handler. If not, then I would not expect any promoted event handler to be working with the DRAG events...which makes this topic moot.

Also, you indicated that the crash happens before it hits the commuter module. I am going to assume that this means it also happens before any event handler code is actually triggered. This seems very much like an unhappy configuration setting with the edit table control, and the moment you invoked the drag operation it just crashes OI. Thus, the need to eliminate potential configuration conflicts such as what might exist in the promoted CREATE event handler.

JimPeters

OK, I figured it out... sort of. It has nothing to do with Frameworks or promoted events. I got the copy of TEST_EDITTABLE_DND I made under Frameworks with very little additional effort. The RTI commuter had the window name hard coded, and I had renamed my copy. Once that was fixed it worked under Frameworks the same way as the original. Our 12+ year old Frameworks is once again proven rock solid and reliable. ;)

The crashes are another matter that seems to be an OI bug. TEST_EDITTABLE_DND and its clone work as expected as long as you drag what you are expected to drag. But, click in the blank space in the upper left corner of the edittable (cell 0,0 I presume) and start to drag towards the center and OI will immediately crash, every time.

I also tried this on a clean 9.40 install without Frameworks or any applications with the same result. I also tried it on 9.21 and the same thing happened. It is the same on any OI edittable with the 3 raw style bits set, uniformly. Otherwise, Drag and Drop works as advertised... just don't try to drag from the upper left corner of an edittable.

I don't know if this happens with all PC's. The only thing even slightly different with my setup is it has 3 monitors attached. Otherwise it is a bone stock Dell with a clean Windows 10 install and plenty of ram.

My solution is not to use Drag and Drop for this. As you pointed out it isn't that great anyway.

Thanks for your help!
Jim

DonBakke

Jim,

Thanks for updating the thread on your results. I'm always glad to hear that SRP FrameWorks does what it is designed to do! However, it is a pity that this OI feature isn't as reliable as you need it to be.

Do you really need this for the edit table control? If the purpose is to allow users to reorder their data, could you provide them a window with the SRP Tree control instead? This would only be for the drag-n-drop operation. Then you would use the results to resort the edit table data yourself. Thus, it still gives the user a way to reorder using a mouse versus the old up/down arrow buttons.