Welcome To The Home Of The Visual FoxPro Experts  
home. signup. forum. archives. search. google. articles. downloads. faq. members. weblogs. file info. rss.
 From: Rick C. Hodgin
  Where is Rick C. Hodgin?
 Indiana - United States
 Rick C. Hodgin
 To: Bernard Bout
  Where is Bernard Bout?
 Bernard Bout
Subject: RE: Realtime DLL update
Thread ID: 373779 Message ID: 373880 # Views: 97 # Ratings: 0
Version: Visual FoxPro 9 SP2 Category: Forms
Date: Thursday, March 28, 2013 1:35:38 PM         

> > I have pushed an addition to Realtime. It's still primitive.
> > No callbacks. Missing a few features (only works with captured
> > graphics right now, no generated text). It might be good enough
> > for a preview though (please report any bugs):
> >
> > https://github.com/RickCHodgin/realtime
> >
> Interesting control this. I have tried it with different vfp
> controls like image, checkbox, combo etc and it draws them.

Yes. It does this by acquiring whatever image is on the VFP form at the coordinates specified. In my testing, it works for everything VFP can draw.

> The dragging of the controls is very nice and smooth. However they
> do not remain where they have been dragged or has this not been
> implemented as yet?

Correct. This functionality has not been implemented yet.

> Ideas.
> 1. Control (e.g. Button) can be re-drawn and when dragged and
> dropped and will remain where it has been "dropped"
> 2. Have a callback on the "Click" of object redrawn (e.g. button) so that
> - After redeaw, the object is clickable
> - Calls back to a vfp method (callback) so that code can be implemented
> - Store the "new" positions in an updatable array or something else
> so that repositioning the control will update that array (or
> something else) such that the new position can be saved so that
> the next time the form is run, it "remembers" the button position.
> 3. Maybe implement callbacks for other object events like MouseUp/Dn,
> MouseMove, MouseEnter etc. so that the redrawn controls (e.g buttons)
> become Live.
> 4. Ability to "acquire" the object even if its Visible = .F. (Already implemented?)

Well ... all good ideas. One note though ... I have no ability to capture invisible controls directly because the only way it can acquire objects right now is through their rectangular coordinates on the screen (it reaches in to VFP's bit buffer and grabs a copy of those bits). The option I have is to generate those bits (as with the current text generation feature, which does not function as released, but will function this weekend). The only real remaining option is to create the control content myself. I have no issues of doing that as I will be drawing all of these controls for Visual FreePro. However, it's not something I have planned for Realtime at the present time.

One extension that will be added in the next release (prayerfully this weekend) is the ability to use a previously captured BMP file as the image that's used for the control. This would allow some "invisible" controls to be captured during development time, making them accessible during runtime by referencing their bitmaps from a binary memo field, or a disk file.

> I believe you have already implemented most of the above (after looking
> at the parameters your class accepts).

Correct. And what you see here is a preview of a great many other things that I will introduce (James 4:15) over this summer, all designed ultimately to come together in Visual FreePro.

> LPARAMETERS tnObjectId, tnObjectType, tnCol, tnRow, tnAnimationId, ;
>             tnDraggable, tnAcceptsDrops, tnCopiesOnDrop, tnCallbackCode

> Not sure how these are used:
> tnObjectId - this is the object id

The objectId uniquely identifies each object. Is assigned internally by the DLL when it's created. Numbers are not reused during a single session of an application. However, upon restart they will begin again. The objectId is used as a handle to instruct the DLL on additional information about that object, and is one of the signal codes used to associate the callbackCode with an object and action (such as when Realtime.dll will signal a mouseDown event on object X, with callbackCode Y).

> tnObjectType = ??

Not used at the present time. I actually thought I had removed this in the version that was released. Perhaps it crept through unexpectedly. :-) It is designed to be a classification of the type of control. Right now you only see controls which appear in a grid using a column/row format. However, future controls will not be rigidly defined in a grid like that, and will take on other attributes such as x/y coordinates, and possibly x/y/z coordinates.

> tnCol/tnRow = Column/Row - Maybe better an X/Y or Left/Top (in pixels)
> for more precise placement for single objects rather than
> row/col as in a grid format? Or maybe both?

See the notes on tnObjectType.

> tnAnimationId = ??

I know for a fact this was removed. I'm not sure why it still appears in the list other than I made the mistake of not removing it from the class. But, it's not used internally any longer.

For background:
Animations were originally created programmatically and assigned to each object. This controlled the opacity of each drawn object when in a normal state (drawn on the screen, mouse is not over, it's not being dragged), when being dragged, when being inserted, and when being placed atop an existing item, as well as the speed with which it moves from its current location to its destination location. However, I later abandoned this and just made all pieces drawn the same way as you see, with some transparency when being dragged, and fully opaque at other times.

> tnDraggable 0/1 - T/F

Yes. Exaactly. It answers the question: "Is this object draggable?" If 0, then it is a stationary object drawn only, possibly responding to other events, but it cannot be dragged to some other place.

> tnAcceptsDrops = ??

Can other objects be dragged onto this object and dropped? It determines whether or not the target objecgt will indicate visibly that it can receive the dragged object if dropped, or not.

> tnCopiesOnDrop = ??

When an object is dragged to some new location, this property answers the question: "Is it copied?" If yes, a copy is made and inserted leaving the original at the location it was originally dragged. If no, then it moves the object to the new location.

This is useful for a filter screen, for example, where a user might drag and drop an "AND" symbol object into an expression. You don't want to move the "AND" object into the expression, but you want to copy it from its legend area into the expression area upon drops.

> tnCallbackCode = ??

This is a custom callback code that can be used when events happen on this object. When combined with some future properties (such as objects being visible or not), different classes of objects can be handled inside the Realtime DLL with feedback being given to VFP about what is happening graphically by user input.

This code / piece-of-information is in addition to the objectId which uniquely identifies the object, and can be used internally to reference something specific to the application. For example, a callbackCode value of 5 might reference the 5th element in an array which contains information about this control, or it could reference the parent container to which it belongs, or any other thing. It is a general purpose value that can be used for anything unique to the peculiar requirements of a given application.

> So How are the above used? Any samples?

Just the one I've released so far. It was more of a proof-of-concept, get-some-feedback, see-if-there-are-any-bugs, type release. It was not intended for prime time. :-)

> I especially like the way the buttons smoothly re-arrange themselves
> a-la-windows8 Metro.

After seeing your live tiles demonstration I kind of had you in mind for examining it. I am glad you responded with some notes.

Some additional plans in the pipe:

(1) In addition to the object itself being a rectangle with particular bits, I am going to provide the ability to define rectangular coordinates within the object which can be updated independently via the insertion of either text or an image. This will be via explicit opaque overlay, or via alpha blending to the original image, or via a color mask (such as use RGB(255,255,255) as a "transparent channel" and convey all other color information).

This would allow a square object to be created with layered sub-components on it, for example, such as for a "weather bug" type control. A part at the top might indicate the nature of the weather outside via icon (sunny, cloudy, rainy, etc.), along with an overlain area for temperature, forecasts for the day, etc.

(2) The ability to save acquired components or generated content as images to disk file.

(3) The ability to programmatically make individual objects visible or not visible.

(4) The ability to specify that certain objects are related via disposition (such as the "normal" image is objectId X, the "dragging" image is objectId Y, the "dropped" image is objectId Z, the "over" image is objectId A, etc.).

(5) The ability to indicate programmatically which events each object responds to (all events will be signaled back to the thisForm.hwnd, where BindEvent() can be used). My planned signals are Click, RightClick, MouseMove, MouseEnter, MouseLeave, DragStart, DragMove (in lieu of MouseMove -- signaled while dragging), DragAbort, DragDrop, and Hover -- Visual FreePro will also introduce RightDragStart, RightDragMove, RightDragAbort, and RightDragDrop, along with Press, LongPress, PinchIn, PinchOut, InertiaMove). I will likely not implement all of the planned-for-realtime.dll events initially, but do plan on Click, RightClick, MouseMove, and DragDrop this weekend.

There is much more planned for this type of design than what has been released publicly (as this is but a small part of Visual FreePro's form designer).

For the public release in realtime.dll, I will complete updates to the realtime_dll and mover classes this weekend (James 4:15), and will get it so it responds to click, movement and drag events properly, and sends back information about those events to the VFP form (thisForm.hwnd for BindEvent()). I will also work on the above options (rectangular sub-coordinates within supporting text, graphics, with transparent color, save, visible, linked events, and event mask settings). After this, I will leave it alone for the most part as the continuation of development along these lines will go into the Visual FreePro forms designer IDE.

I do appreciate your comments, Bernard. They were a welcomed surprise this morning.

Best regards,
Rick C. Hodgin


Realtime DLL update Posted by Rick Hodgin @ 3/26/2013 11:05:56 PM
RE: Realtime DLL update Posted by Bernard Bout @ 3/28/2013 9:53:02 AM
RE: Realtime DLL update Posted by Rick Hodgin @ 3/28/2013 1:35:38 PM
RE: Realtime DLL update Posted by Rick Hodgin @ 4/1/2013 12:37:25 PM
RE: Realtime DLL update Posted by Rick Hodgin @ 4/6/2013 3:48:01 AM
RE: Realtime DLL update Posted by Rick Hodgin @ 4/9/2013 2:22:14 AM
RE: Realtime DLL update Posted by Jun Tangunan @ 4/9/2013 3:59:08 AM
RE: Realtime DLL update Posted by Jun Tangunan @ 4/9/2013 3:59:08 AM
RE: Realtime DLL update Posted by Rick Hodgin @ 4/9/2013 11:49:59 AM
RE: Realtime DLL update Posted by Bernard Bout @ 4/9/2013 4:15:16 AM
RE: Realtime DLL update Posted by Rick Hodgin @ 4/9/2013 11:36:24 AM
RE: Realtime DLL update Posted by Rick Hodgin @ 4/9/2013 11:48:00 AM
RE: Realtime DLL update Posted by Rick Hodgin @ 4/9/2013 12:04:51 PM
RE: Realtime DLL update Posted by Rick Hodgin @ 4/9/2013 2:22:53 PM
RE: Realtime DLL update Posted by Rick Hodgin @ 4/10/2013 2:51:26 AM