Beiträge von LOGO Datensysteme

    Hi Julian,

    thank's for the hint with initially setting the content with an empty string during INIT. That did it.

    So for all you folks out there...

    When you attempt to make an absolut readonly-not-selectable text, you should be sure to initialize the "editor" during the init-phase with an empty string and set the READONLY / Not-Selectable Flags afterwards.

    So in addition to above example code in VFP9 SP2 there is only a minor change:

    So... Problem solved.

    Thanks and best regards
    Michael

    My above example sets the flags during the init of the object.

    During runtime i set the content via SetText(...), after which i experienced the problems that the flags for ReadOnly are ignored...

    After playing with it a littlebit more, i found out that using SetText on a MEMO that is flagged READONLY most of the flags originally set to READONLY are automatically resetted which causes the text to be editable again.

    Julian, if this behaviour is on purpose, perhaps you could place a comment in the helpfile to SetBProp() so that this behaviour-info is available to all.

    Not all flags are resetted, e.g. SetBProp(0,7,1) for hyplink-one-click is still set after SetText().

    So, at least under VFP9 SP2 the following sequence in which the flags and text is set is important.


    Using the SetBProp(...) for ReadOnly, DisableSelection... during INIT will NOT work correctly as ReadOnly is (at least partly) resetted to Editable when using SetText(...) on later occasions.

    I don't know if this behaviour is VFP9 only or if it is on purpose, but i can now confirm that with this sequence by setting the readonly-flags again after changing or setting the textcontent a real readonly-display is still possible.

    I hope this helps some of you guys out there, because TextDynamic is by far the best rtf/wordprocessing editor-ocx you can find for using in Microsoft Visual Foxpro. So stay tuned for more info on usage with VFP9 here on the forum. :-)

    Using the OCX version of Textdynamics i use the "editor" as a readonly-viewer of RTF-files from different sources.

    That works pretty good with only one exception.

    Even with shutting off every "interactive" part by setting memo.readonly and several additional Flags with SetBProp(...) so that not even the InsertCaret is visible, Hyperlinks are working with one-click and so on...

    That's great, but there is on flaw i was not able to "shut off".

    Perhaps i overlooked something i should have set too, but i suspect it's somekind of flaw / error.

    When the RTF conversion (using Premium-Lic) brings textboxes or in my case movable-images to the text, theses images or textboxes are not affected by any of the ususal Flags. Even with all flags set to "readonly, no-selection, no-handlemark, no-nothing..." i can still select the images/boxes.

    After selecting the box shows the typical handles and i can move it around and/or resize it any way i like which i should not be allowed according to my settings.

    I use the following settings. THIS is a reference to the TextDynamics element itself.

    Has anyone an idea what's going wrong here? Any suggestions how to shut off this interactivity too?

    Thanks and regards
    Michael

    Hi there,

    the option dialog for the textcorrection is of wrong window type. It shows as sizable but should be a nonsizable-dialog style.

    Also the originalwidth is a tick too small.

    You can see that the buttons on the right side are partly outside the visible area:

    [Blockierte Grafik: http://www.betreuung.de/grafik/img3.png]

    As this dialog has sizable style it can be resized, but without the actual object on it taking note of the resize:

    [Blockierte Grafik: http://www.betreuung.de/grafik/img4.png]

    [Blockierte Grafik: http://www.betreuung.de/grafik/img5.png]


    The windowstyle should be set to dialog nonsizable and the original width should be changed to include the windowcontent completely.

    Best regards
    Michael
    LOGO Datensysteme GmbH

    Hi,

    we are using the OCX in Microsoft VisualFoxpro 9 SP2 with great success. There is only one glitch, that under this environment is shown by the OCX. This behaviour is not shown of the very same OCX when used under C# or C++

    The windows used by the subitems of the toolbars or panels are not "connected" to their "parentbutton". Under VFP9 i can move the mainform when such a subitem-window is open. The subitem-window is NOT closed (as it is under c#/c++), but stays open at its position where it was when it was initiated.

    This looks like this:

    ColorPicker when clicked on Button
    [Blockierte Grafik: http://www.betreuung.de/grafik/img1.png]

    After moving the main window that holds the ocx by dragging the window with the mouse.
    [Blockierte Grafik: http://www.betreuung.de/grafik/img2.png]

    This issue happens to ALL subitems from the toolbar or the other Panel-SubItems.

    I know that VFP9 is something special because the forms of a VFP9 application have all the same HWND as the MainWindow of VFP itself.

    I suspect that TD binds itself with it's events to the main form which is not triggered by VFP "subforms". It should be better to attach itself to the HWND of the OCX itself. Because the ocx-window itself is moved by VFP during moving the mainform you should be able to detect the movement of the window.

    If needed i could provide an example EXE which shows that behaviour.

    Hope you could provide a solution for this.

    Best regards
    Michael

    LOGO Datensysteme GmbH
    http://www.betreuung.de | http://www.datensysteme.de