bb.donnay-software.com

Hi, Roger.

If a dialog is created with DC-commands, it may be needed to resize/repos objects without using the RESIZE-stuff from eXpress++. Sample: I have a huge dialog with several objects on it and a big browse. If the user selects a special option, some nested browses are displayed (hidden when the dialog comes up, behind the big browse), and if the user deselects the option, they are hidden again - just an example. In other situations, a groupbox should be bigger/smaller depending on the user interaction.

In those cases, I recalculate all object sizes and positions using CurrentSize(), CurrentPos(), SetPos(), SetSize(), SetPosAndSize() and so on (AUTORESIZE is off in those situations). This works, but it's a mess, since on the other hand, some dcget-options like WINDOWROW can be changed by users. So:

What about functions like DC_SetPos() ... using the row/column coordinates? This:

@ 1,1 DCBROWSE oBrowse ... SIZE 20,100

oBrowse:DC_SetPos(2,1) moves this browse to the second "line" (20 pixels downwards if no special option is set)

Just a suggestion. This would be very helpful and ease the coding.

Tom -

All DC_Xbp*() classes inherit from DC_XbaseParts() so it would be real easy to make these methods work for all classes, but I'm not quite sure I understand what you want. Could you be a little more clear about what you want each of the methods to do?

Roger

Hi, Roger.

I just want to resize/move objects created with DC-commands using the DC-coordinates. It does not have to be a method. This may position oBrowse at 7,580 (bottomleft, pixel coordinates). The size of the browse is 700,550 (pixel). CurrentPos() and CurrentSize() may return these values.

Suggestion: -> moves the browse to 7,560 (pixel), for instance. -> resizes the browse to 560,400 (pixel) and doesn't move it. The "beginning position" remains.

But I can do this by my own. The offset values (7 pixels: one column, 20 pixels: one row) are inside GetOptions. It was just an idea. If this is not helpful for others, forget it.

Ok, I think I am understanding now what you want.

I believe that if they were methods, they would be easier to write and to use.

So these methods would use 0,0 as the top left instead of the bottom left and would translate from text-based to pixel-based.

I'll write something and send it to you for testing.

Tom -

I think this is what you want.

I added the following new methods to DC_XbaseParts().
These will be inherited by all DC_Xbp*() classes:

dcSetPos()
dcSetSize()
dcCurrentPos()
dcCurrentSize()

Here are 2 new files:
http://bb.donnay-software.com:8080/support/_dcclass.prg - Copy to \exp19\source\dclipx directory
http://bb.donnay-software.com:8080/support/dcsetpos.prg - This is my test program

Roger

Hi, Roger.

As I reported - this works really good. But it seems that the resizing/repositioning is not reflected by the GetList array. If i.e. a browse is resized with oBrowse:DCSetSize(a), and the dialog containing it is resized using DC_AutoResize() afterwards, the browse resizes to the initial size (the size it had when the dialog was created).

Tom

Tom -

Sorry, I missed your post.
I'm working on that problem today.

Ok, I think I have it.
It passes my tests with the original test program.

Copy the attached _DCCLASS.PRG to \exp19\source\dclipx and run BUILD19_SL1.BAT to rebuild DCLIPX.DLL.

Roger

Hi, Roger.

This creates an error at DC_XbpActiveXControl:Init(5153), Parameter has wrong type (<\CLSID\> + <0>).

Tom.

This makes no sense.

I added some new code to DC_ActiveXControl() to allow for automatic registering of an OCX, but that code isn't excuted unless you also have the new DCDIALOG.CH with the REGISTER clause.

Could you please send me your DCDIALOG.CH file?

Hi Roger,

That register clause is a nice addition. Is it already tested for the codejock ocx files?