drag/drop edit box over grid 1

[arielap]

I have a grid with an edit box (showing data from another table) that pops up over the grid when a particular condition is met.

The users would like to be able to drag the edit box around, to uncover whatever part of the grid it is on top of.

I've tried following examples in Foxpro and elsewhere, and can move an edit box round an otherwise empty form, but extrapolating the code to when the editbox is over a grid did not work - the box jumps back to its original position when the mouse is released.

Is it possible to d&d an object OVER a grid - if so, how please

 

[Mike Lewis]

An easy option would be to put the edit box in its own form. Make the box fill the form. Make the form modeless, and always on top. The user will then be able to drag the edit box anywhere they like simply by dragging the form's title bar.

If that solution isn't appropriate, you can easily fix it so that the edit box itself is draggable:

1. Set the edit box's oleDragMode to 1.

2. Write code in the oleDragDrop of any objects on which the box can be dropped. In this case, that means the grid, the containing form, and perhaps other controls in the form (including possibly the edit box, in case the user drops the box on itself).

3. In each case, the oleDragDrop code will call the edit box's Move method to move it to the relevant position.

4. To calculate the relevant position (where the drop will take place), use ObjToClient(). This will help you work out the position of the mouse pointer relative to the form.

If your aim is simply to let the user move the edit box so they can see what's underneath it, I have to ask why you position the box on top of the grid in the first place. Why not simply place it to one side, so the user won't have to move it out the way?

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[arielap]

thanks - I'll try your second option but -:
>> If your aim is simply to let the user move the edit box so they can see what's underneath it ...
Why not simply place it to one side>>

That is exactly what we want. But the grid(s) - there are three(tabbed)in this pageframe - each almost fill the screen when on top and can't sensibly / functionally be reduced.
This is a transplant immunology app - lots of antibodies and related data and the users need to see certain groups of data together on one screen.

 

[Olaf Doschke]

If you really have a secondary table, which is displayed in an editbox, then there must be code generating that editbox control directly on the form, thus not movable. Foxpro itself would pop up a draggable popup form, if we talk about "Memo" inside a grid cell.

I would second Mike on his thought to simply put the editbox into a seperate form, like foxpro does, when you double click a "Memo" displayed in a textbox, like the grid's default is.

I also wouldn't suggest making that generated editbox draggable, that only sounds easy to do in the first place. That always has two sides: You would need to put code into anything on the form accepting the "drop" of the editbox, changing it's position. Therefore it's much easier to generate a form than a draggable control.

Bye, Olaf.

 

[arielap]

Thanks
>>If you really have a secondary table, which is displayed in an editbox<<
It's just one (memo)field from a primary table (holding individual patients) which pops up ONLY if not empty, over a related table grid which shows all the results for a specific test for the patient selected from the primary.

I'll experiment with the suggestions in your and Mike's reply

 

[Olaf Doschke]

So, if that's a memo popup it is movable, unless the form is modal. But then also a normal second form won't help. Make the for showing the patient data nonmodal and you'd be good.

Bye, Olaf.

 

[arielap]

thanks - I'll have a play over the weekend

 

[arielap]

Using a second form for the memo data works fine for dragging the 'edit-box' over the underlying grid.
But it has to be actively dismissed before the users can use the scrollbars or add/edit data in the grids on the underlying screen, - which they want to do with the contents of the memo field still visible.

Making th edit box draggable would be too complicated - and they only want to be able to drag the box, not drop it

I think the answer may be a plain non-oop window?

 

[Olaf Doschke]

arielap,

just make sure the form with the grid is nonmodal, then the editbox will be movable, it's the normal popup form foxpro generates for memo fields, it's just stationary, if the form is modal, as then no other form can get focus and thus cannot be moved. That's the whole problem.

Bye, Olaf.

 

[Mike Lewis]

Arielap,

You say the edit box form has to be "actively dismissed".

You have a couple of choices. If both forms (the one with the grid and the one with the edit box) are modeless, then you don't have to dismiss the edit box in order for the user to interact with the grid.

However, as soon as they click onto the grid form, the edit box will disappear. It won't close. It will simply be hidden behind the grid form.

To prevent that, make the edit box form "always on top".

The user will then have to click the edit box form's Close button in order to dismiss it. Alternatively, you can write code in its Deactivate event to release the form. That way, the form will close whenever the user clicks anywhere outside it.

Another option is not to close the form at all (except when the application closes). Instead of closing it, just set its Visible to .F. When you want to open it again, set it back to .T.

If either or both forms is modal, the user will have to explicitly close the edit box form, by click its Close button. There's no point in putting code in the Deactivate event, as that will never execute. But if the forms are modal, the user won't be able to interact with the grid while the edit box is open.

Hope this helps.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips, training, consultancy

 

[arielap]

>>just make sure the form with the grid is nonmodal<<

tried that (and with the edit form non-modal and on top) but predictably the grid form flashes off as soon as called.

I should explain that this only part of a larger app. The form with the grids (CYTO) is called via a submenu of options for a specific patient selected earlier from a different table (RECIPS), and the edit box, which shows a memo field from RECIPS, only needs to appear over the CYTO grid IF the memo is not empty AND a control on CYTO, (which is not visible if that field is empty) is pressed.
The memo information needs to remain visible while the users work on the CYTO grid.

At present, with the edit box as an object in the CYTO form, this works as intended, the static box covers relatively unimportant fields from the oldest CYTO records on the page and can be quickly toggled off and on again. But the ability to just drag the box briefly out of the way, without dropping it anywhere would be neater.

If this can't be (easily) done - which now does seem likely - I'll just leave it 'as is'.

Thanks for your help gentlemen

 

[Olaf Doschke]

Well,

that's what I feared. The callee is not programmed in a way to let the patients form be nonmodal for some reason.

Can you post the code calling the patient form? Is it a DO FORM line, simply, or is it a CreateObject("patientform")?

Both scenarios have a solution in putting the form object into a collection so the form stays alive in memory.

First of all, somewhere in your app start code add a collection to _screen to hold form references there:

_screen.addobject("formcollection","Collection")

Then add forms to that collection, if they are nonmodal, they will then be kept alive and automatically remove themselves from the collection, when they release.

  * alternative1:
  loForm = CreateObject("patientform")
  _screen.formcollection.Additem(loForm)
  loForm.Show()

  * alternative2:
  DO FORM patientform with ... Name loForm NOSHOW
  _screen.formcollection.Additem(loForm)
  loForm.Show()

NOSHOW makes shure the code continues no matter what type the form is, the form is made visible via the loForm.Show() call in both cases.

Bye, Olaf.

 

[arielap]

They are called with 'DO FORM .. and all forms except pick-lists need to be writable to. What is shown depends on a variety of conditions and most are linked to other forms or PDF files.
The app is used by a (human) transplant unit, mainly dealing with immunology and donor/recipient interactions. and is quite complex.

I'll have a play with your code when I've more time. The drag function is is only a very minor 'it would be nice if' addition and I was hoping I'd just missed an obvious VFox function.

Thanks anyway

 

[Olaf Doschke]

> I was hoping I'd just missed an obvious VFox function.

Well, yes, the function to keep focus on forms which are modal. Making them nonmodal changes that so you can also focus and therefore also move a popup form like the editbox popping up from a Memo field.

Making a form nonmodal doesn't change the form to be readonly, the only thing that changes is, the caller does not need to wait for the form to finish. In many cases this means the form vanishes instantly, as the variable holding the called form references then get's out of scope and therefore the form closes. To avoid that use the code I've given. As you say it's DO FORM calls, use alternative2 of course.

Bye, Olaf.

 

[arielap]

Thanks - I'll play when time permits.