Beiträge von LOGO Datensysteme

  • TextDynamic OCX and PrintDialog with Copies

    Hi there,

    we are using the OCX under VisualFoxpro SP1 to great success.

    Is there any way to change the number of copies to print when using the Printdialog via wpaProcess("printdialog","")?

    I found severeal delphi-codebased examples which of course have access to Printer.Copies. This is obviously not possible with the OCX (at least i don't see it).

    Of course i could use my own dialog, but then i would have to do "all the work" on my own. I would like to stick to the build-in-dialog.

    Any idea on how to achieve this?

    Thanks
    Michael

  • Backgroundcolor of Selection

    Does anybody know if and how the color of the selection can be changed?

    And with selectioncolor i am not thinking of the backcolor of the selected text/paragraphs, but the actual color of the selectionmarkings itself.

    Currently the color is close, but not the same, to the lightblue of a selection in Word. I would love to change that.

    Best regards
    Michael

  • Faulty behaviour of subitem-DropDowns when moving main form

    Hi everybody,

    until Julian finds a generic solution, i found a workaround for VFP users that work pretty good. So here for those who are interested the Workaround:


    1.) Insert another CommandButton onto the Form holding your TD-object. Place it OffScreen so that it is never visible (like at Postiion -100,-100) AND set the TABSTOP Property to .FALSE. (so it is not reachable to users using TAB-key)

    2.) In the FORM.Moved Event put the following code (adapt to your objectreferences)

    Code
    IF this.ActiveControl.BaseClass="Olecontrol"     IF this.ActiveControl.OleClass="WPTDynInt.WPDLLInt"            this.oDummyCmdButton.SetFocus()     ENDIF ENDIF

    We double-Check if the focused Object is actually the TD OCX itself, because only then we'll have to do the focus-manipulation. And due to the fact that we move focus when this is true, the setfocus() is done only once. This is important, because the Moved() - Event comes quite often during moving the form.


    3.) In the KeyPress-Event of the Dummy-CmdButton put the following code (again adapt to your objectref)

    Code
    * Put the Focus back to the actual TD-OLEObjectthisform.rtf.rtf.SetFocus()* nKeyCode and nShiftAltCtrl are parameters of the KeyPress-Eventif nKeyCode=93 AND nShiftAltCtrl=1        * Special Treatment for Win-ContextMenu        DODEFAULT(nKeyCode,nShiftAltCtrl)ELSE        NODEFAULT        =api_SendInput(nKeyCode,nShiftAltCtrl)ENDIF

    KeyCode=93 AND nShiftAltCtrl=1 happens only when in this situation the WinMenu-Contextmenu-Key is pressed. We hand this off to the DefaultKeyHandler of VFP.
    Otherwise we stop handling the Keypress (=NODEFAULT) and stuff the whole Keypress-Stuff back into the Windows-Handling.

    Here is the code for the API_SendInput() - Function:


    Until Julian finds a way to give us the actual HWND of the OCX this code actually triggers a true WM_KILLFOCUS because of the Focus-Moving to another VFP-Object and puts the focus right back if a key is pressed after moving the form.

    When we have the HWND this code will be obsolete and one should simply send a POSTMESSAGE(hwnd, WM_KILLFOCUS) to the OCX.

  • Problem with OwnerPW in PDFcreator from TextDynamic

    Hi Julian,

    nope... that's not the reason why it fails.

    The COM-Properties are indeed presented with correct UTF - Stringformat. The neccesary conversion between datatypes in the COM-Object and Strings within VFP is done transparently. As all other String-Properties and -parameters of the TD COM object are working perfectly well, i can assume that this also works well for these specific PDFcreator.props.

    There are several "switches" with which i can change this autoconversion behaviour. I tested all of it and even tested switching off the autoconversion and doing the ansi-to-unicode(wide) - conversion myself before stuffing the string onto the UserWP-Property.

    Bottomline: I am 100% sure that at least it is the correct String-Type that is presented to the COM-Property here AND i am sure that the EditorMode is set correctly too. The export to PDF is working and all the nice little settings like DontAllowPrinting, NoEditing etc. are set correctly in the resulting PDF.

    But... From my side of the fence i can't see what data is actually reaching your kernel-DLL because of the different wrappers used here. VFP-OLEcontainer wrapping the OCX wrapping the DLL-calls...

    I could offer you to build a little VFPbased Testprogram that uses the TD OCX to build such a PDF. With that you could test the behaviour and the data you actually receive in a debug environment with your tools.

    Any Idea?

    Best regards
    Michael

  • Problem with OwnerPW in PDFcreator from TextDynamic

    Well... that explains a lot.

    As i assumed... it's DoubleByteCharacter - String. Foxpro uses only SingleByteCharacter. Which, when just handled without test and used along the resulting password in the pdf will be garbage.

    I'll just have to change the string to DBC / Unicode and feed the PDFCreator with that.

    I will test tomorrow and post back the result.

    Until then... have a nice evening
    Michael

  • Faulty behaviour of subitem-DropDowns when moving main form

    Great Idea...

    I will give it a try... I'll do a sendmessage() to the HWND of the OCX with WM_KILLFOCUS and have a look what happens...

    But WM_KILLFOCUS doesn't feel quite right for this (even if it might work), because the point is: You are not lossing focus here, because the Mainform just moves due to MouseOperations. That wouldn't count a a FocusLost-event.

    When i setfocus to another VFP.Objekt (and therefore TD is loosing it's focus) the submenu closes right away and works perfectly.

    Perhaps that's the point. There is no KILLFOCUS because TD should actually keep the focus when the mainform ist "just moving around"...

    Anyway, I'll have a test an report back what's happening.

    Best regards
    Michael

  • Problem with OwnerPW in PDFcreator from TextDynamic

    Hi Julian,

    i tested a littlebit more and would like to add the following findings:

    If i use the internal-dialogbased method with

    Code
    thisform.rtf.rtf.wpaProcess("DiaPDFProperties","")

    everything works just fine when i choose a security setting with OwnerPassword. The resulting PDF is protected with the very same choosen password.

    Unfortunately this dialog is no way to go for us. As we often need a no-dialog way (via the ServerLicence) to produce PDF. As an additional annoyance the dialog is english-only (at least i have not found a way to switch language to german) AND you put a very prominent hyperlink to your website on the dialog which is IMHO not very acceptable for a fully licenced component.

    As my target was a no-dialog-pdf-production anyway, i stick to my first intention with a code-only attempt.

    But the following code as an alternative to dialog-based does not work:

    I think this code is pretty straight forward. The resulting PDF opens with perfect content and shows under Adobe Reader 9 as "(GESCHÜTZT)" (german for "Protected"). The DocProperties are indeed protected and when i try to enter it i am asked for a password, but unfortunately nothing works here. Adobe always complains about "wrong password".

    Perhaps this is again something like the BeginPrint/Endprint - thing where this is simply ignored when used directly. Any other way to stuff the Passwords into your object? Something like the TextCommandStr for the MEMO... ?

    Anything yet from looking into it?

    Thanks and best regards
    Michael

    ---
    Just a hunch... What format has the PW? VFP works with single-byte-ANSI. Is it possible that you need Double-Byte-Characters here? UTF-8 ?

  • Help needed for BeginPrint(....)

    Zitat von wpsupport

    Hi,

    Please use Memo.BeginPrint - that should work ok.

    Hi Julian,
    thanks for your reply and sorry for taking so long to test. I was on vacation...

    For a moment i was confused as the MemoObject hast no BeginPrint/EndPrint - Methods, but then i understood your intentions. For the sake of all who are looking for a solution here is the working VFP Code:

    Code
    WITH thisform.rtf.rtf as WPTDynInt.WPDLLInt 
   .Memo.TextCommandStr(13,0,"TestPrint von Michael") 
   .Memo.Print 
   .Memo.TextCommandStr(14,0,"")
ENDWITH

    Using the TextCommandStr as a replacement for the not unresponsive Begin/EndPrint this works perfectly well under VFP9 SP2 and showing the printjob under windows as "TestPrint von Michael".

    Thanks for the hint.
    Michael

  • Help needed for Filename in SaveAs / Save Dialogs

    Hi there,
    my question of the day is about the filename used in save- and saveas-Dialogs.

    We use a lot of temporary RTF - files that are generated by our program with a random-temp-name in the Windows TempDir and open this in TextDynamic with LoadFromFile(...). Works great!

    When i now want to save the content to a file using one of the Dialogs (e.g. using wpaProcess("DiaSaveAs") ) the temp-filename of my content shows as proposed filename in the dialog.

    Of course i am setting Memo.SetInitialPath(0,"....") to my wanted save-dir, but i have found no way to influence the actual filename that is proposed in the savedialog.

    Is there any way to achieve this? Currently i would have to save the content to the TempDir first using my wanted filename just to change the "Name of the document" after which i offer the actual save-dialog in the wanted save-dir. In general this is far too much disc-IO just for changing the document-name. Especially when i have to delete the temp-file afterwards...

    Any Idea anyone? Perhaps i am just missing something here. If not, i strongly suggest a DocumentName Property which is than used for purposes like this.

    Thanks and best regards
    Michael

  • Tableborder color is wrong on black/white printer

    Me again ;-))

    Using the latest TextDynamic OCX in VFP9 SP2 i have a problem with the print result of an RTF text loaded with memo.LoadFromFile().

    The RTF itself contains tables with grey bordercolors and some grey backcolor. On Screen the text is correctly presented and even with pdf-export the tables show perfectly with greycolored borders.

    After some testing i found the following:

    When the selecting Printer is capable of color the print is perfect. It makes no difference if it is real hardware like an HP ColorLaser or if it is a virtual color-aware printer like MS XPS Printer or SnagIt 10 VirtualPrinter.

    If i choose a black-n-white Brother Laserprinter as printtarget, the borderlines are printed as black-solidline whereas the originalprint (e.g. with Word 2007) is of course with grey lines.

    So on black-n-white printer the print is not what it should be.

    This "conversion" is done for the "lines" of the tableborder only. If i add colored or grey text to the RTF the text itself is printed perfect on all printers.

    In addition to the "color-problem" sometimes the borderlines are not printed at all, which is even more annoying than solid-black-borders...

    My conclusion: TextDynamics analyses what the PrinterDriver is capable of and adapts the print behaviour accordingly (at least for some of the "painting"). I think this is wrong, because most of the Drivers out there have code to adapt colors to emulated greyshades which works pretty good. TextDynamic should not proactivly make the printing 100% black just because the printer says it's only black/white.

    I would say the source of the problem is to be found somewhere in the "paint lines"-routines because it's only with these where the problem occurs.

    I can provide scanned PDF of both printresults (colorprinter and black/white Printer) and the original RTF if it is of any help for you.

    Any Idea?

    Best regards
    Michael

  • Problem with OwnerPW in PDFcreator from TextDynamic

    Hi there,

    i was experimenting with the PDF creation abilities of TextDynamic. Quite impressing...

    But i stumbled across something i have have no explanation for.

    The following VFP9 SP2 code sets some security settings for the export including password for the Owner. The exported PDF is perfectly OK and shows all signs of a "secured" PDF. Unfortunately getting access to the PDF.settings part with Adobe Acrobat 9 fails with "wrong password". Even when i hardcode the password (like in this test) Acrobat does not accept the password. Very weird.

    VFP uses regular ANSI as Charset. Is it possible that OwnerPW is expected to be something different?

    Any ideas anyone?

    Thanks and best regards
    Michael

  • DiaExportToPDF uses different dialog then diaSaveAs

    Hi Julian,

    me again ;-)))

    Here is something for the next build of TextDynamic (OCX)

    The windows "save"-dialog you use for DiaSaveAs (sizable and well-known-places) uses different windowstyles as the "save"-Dialog you use in diaExportToPDF (non-sizable, no-places).

    I suggest that both Dialogs uses the same settings. If possible it should be the full-flagged save-dialog from Windows. Under Win7 that should show the dialog with favorite-places and the explorer-tree on the left hand side. If that is not possible, the save-as-Dialog should be always look like the one already in use by diaSaveAs.

    ...and both dialogs should be sizeable which the diaExportPDF unfortunately is not.

    Thanks alot and best regards
    Michael

  • Help needed for BeginPrint(....)

    Hi Julian,

    when printing with PrinterCue everything works just fine when using the following code. The only "mistake" is, that the PrintTitle which is provided is ignored.

    The code is VFP9 SP2 using latest TextDynamic OCX

    Code
    WITH thisform.rtf.rtf as WPTDynInt.WPDLLInt
	.BeginPrint("TestPrint_Michael")
	.Memo.Print
	.Memo.Print
	* using .Print 2x prooves that Begin/Endprint works just fine
	.EndPrint 
ENDWITH

    This Code will always show up in the Windows print queue with "Printing 09_32_34" as the Documentname. This name is always the same, no matter how often i print.

    Alternatively using TextCommandStr instead of the "direct"-methods gives just the same results.

    So any idea about this? Or am i just getting it wrong what the "PrintTitle" on BeginUpdate(...) is and where it should show up?

    Thanks alot and best regards
    Michael

  • Faulty behaviour of subitem-DropDowns when moving main form

    Hi Julian,

    a possible workaround could be that i trigger something from my form.moved-Event.

    Is there any method, property, command ... in the wpdllint object i should call to trigger a "refresh/repaint" of the current content including closing or moving the opened dropdown-windows?

    I can do a win-sendmessage to something when you tell me what and with what message i shall call...

    Perhaps you have a chance give the hwnd of the dropdown-window so i can "destroy" it myself. Or you add a possibility like "wpDLLint.CloseAllDropdowns" so that regardless of the current status of possible Dropdowns all these windows can be closed programmatically.

    Just my 5cents on this... :)

    Best regards
    Michael