I would like to know the way of printing in Power Builder V12 Web Application(Web Forms) [Power Builder Web Application is converted to ASP.Net Web Application]
This feature is new in PowerBuilder V12 and few examples and documentation are available.
I know there is no direct way for printing as there is a need to define a virtual printer
then prepare the document to be printed and send it to that printer.
If any user tried that before or has any examples for that please send them for me.
Thanks in Advance ..
In PB Web Forms, I've identified three ways of printing. I'm going to assume you mean printing DataWindows, as that is most common in PowerBuilder applications.
First is to do nothing to your code and let PowerBuilder handle the DataWindow.Print() function calls. It creates UI elements to link to a "Print Manager" window which is generating PDFs for your user, which the user can then download from the Print Manager.
Second is to leverage the DataWindow.SaveAs (..., PDF!) functionality, and calling the DownloadFile() function on your own trigger. This achieves the same ends as the first, but allows you to manage your own UI.
Third is to show the DataWindow on a page, and use a button that calls JavaScript to fire the browser's own print command. You probably lose some formatting control with this option, but it allows an actual print function to occur instead of just a PDF generation.
And a minor FYI, Web Forms generation from PowerBuilder has been around since version 11.0. That's about the time I started using it, which is how I came up with these options. (These things take time for me.)
Good luck,
Terry.
Related
When developing a WebOS application with Enyo, is it possible to access the clipboard contents? That is, if I copy a bit of text to the clipboard on a Touchpad or Pre device , can I programmatically grab that piece of text, or programmatically replace it?
From what I've read in the SDK documents, I assume I'd need a Service to do this. Is this correct?
If so, which service? Are there a list of services available, and/or is there a way to reflect into the framework to see which services are available?
(New to WebOS development, so error on the side of speaking loudly and slowly)
I think you are looking for the getClipboard method on the enyo.dom. However, when I try:
enyo.dom.getClipboard(enyo.bind(this, "gotClipboard"));
gotClipboard: function() {
this.log(JSON.stringify(arguments));
}
I just get {"0",""}, even though I have text in the clipboard. It makes me wonder if this isn't fully baked yet. One argument will be the text in the clipboard when it works.
If I try the companion enyo.dom.setClipboard, I get a NOT_FOUND_ERR: DOM Exception 8.
Found both of these functions in here: https://developer.palm.com/content/api/reference/enyo/enyo-api-reference.html
Hint: this one might sound complicated, because I am trying to give as much info as possible, but I suspect that I just want someone to tell me "yes, you are correct".
On this legacy system, which dates from 2002, the user visits a web page and uses an RFID reader to read a tag number, which is then written to an input field on the web page.
The only s/w that comes with the reader is a custom DLL, nop .exe.
The very sparse documentation insists that only MSIE be used and that all security relating to ActiveX be disabled.
When I look into the source of the web page I see calls to functions in the DLL.
Now, here's the fun part: I know zilch about ActiveX, I have to make a minor change to the DLL *but* the VB6 source code has been lost, so I guess that I have to recreate the (seemingly very simple) DLL from scratch - this week.
Decompiling the DLL shows me the functions (locateReader, getTagVal, closeReader). However, by decompiling I can't really know the number or type of the parameters, nor the return values ... and if anyone knows the API they are refusing to share it, but basically it all seems to have been lost in the mists of time as companies went bust, were bought & sold, merged & demerged and the initial DLL might have been written by an external guy, but no one knows who.
So, can I get the function params & type from the ASP page source?
I see things like
Reader = new ActiveXObject("<dllName>.Reader");
Reader.locateReader();
tagVal = Reader.getTagVal();
Reader.closeReader();
So, I would say that none of the fn()s take parameters, that closeReader doesn't have to return anything; it looks like locateReader doesn't return anything either, so I guess that error handling will have to be in the DLL (loop forever with a popup demanding that a reader be attached; and getTagVal seems to return a string.
Does that sound about right? Any other comments (other than lessons to be learned)?
The 'code' you've put here looks like the a direct call to the device. And getTagVal() seems to get the RFID value? Since this is an COM (Active X) call can you call this in a simple .net program and see if you can access the reader? If you can then you may be able to just wrap the existing functionaliy in your wrapper.
You need to try and generate a TLB from the component:
So, if you only have a COM dll, you
need to get an idl-file from it:
Visual Studio, start it and go to the meny Tools->OLE/COM Object Viewer.
This is called oleview.exe and can also be got from the windows sdk
In that application, select meny File->View Typelib..
Select the COM dll and you will see the Typelib.
Select the meny File->Save as. Save it with an appropriate name. For
example "mycom.idl"
start midl.exe or mktyplib.exe with the idl-filname as the argument. "midl
mycom.idl"
Read MSDN for more info about midl and
mktyplib
The purpose is to generate proposal documents that can manually be edited in Word after the fact, but before sending them out to the customers.
Much proposal content would be drawn from existing HTML website content (backing CMS) and also some custom (non-HTML) injection for certain scenarios. Of course the conditional logic could go into server-side ASP.NET to vary the content appropriately.
I'm open to 3rd-party tools if raw manipulation of the Word API is arduous. In fact a good 3rd party tool might be the answer.
Use the Aspose Words component for .Net.
Aspose Words Component Link
The component natively understands the Microsoft Word file format without having to install any Microsoft Office products on your application environment. You can then start from an existing word template or programatically build up an entire Microsoft Word document from scratch. The Word object model then allows you to export to doc / docx etc and save as a native Word file to wherever you required.
They have plenty of demos set up on their website.
I've not used any third-party tools before, as I've only ever written Office automation applications for PCs which already have Office installed.
Creating documents from scratch, or basing them on a template, is quite straightforward. With templates, you can define bookmarks and mail-merge fields to make finding and replacing document elements easier.
Here's a few things that you may find useful:
Named and Optional Arguments
The Word object model is reasonably easy to work with. VB.NET used to be easier to work with than C#: as the Office automation APIs were originally written with VB in mind, you could take advantage of optional parameters. In earlier versions of C#, you had to specify every argument in API calls, which was quite tedious. I understand that this has changed in Visual C# 2010:
How to: Use Named and Optional Arguments in Office Programming (C# Programming Guide)
http://msdn.microsoft.com/en-us/library/dd264738.aspx
Tutorials
I found these tutorials quite handy:
Automating Office Programs with VB.NET
http://www.xtremevbtalk.com/showthread.php?t=160433
VB.NET Office Automation FAQ
http://www.xtremevbtalk.com/showthread.php?t=160459
Understanding the Word Object Model from a .NET Developer's Perspective
http://msdn.microsoft.com/en-us/library/aa192495%28office.11%29.aspx
Early and Late binding
One point worth mentioning: late-binding is normally recommended against, but it can be very useful if you don't know what version of Office will be deployed on the application's host. Early-binding tends to operate faster, and has the advantage of intellisense in your IDE:
Using early binding and late binding in Automation
http://support.microsoft.com/kb/245115
Early vs. Late Binding
http://word.mvps.org/faqs/interdev/earlyvslatebinding.htm
Search and Replace
One thing to be aware of is that the find and replacement objects may not work as you would expect. Rather than searching the whole document, it searches just the main text. If you have text frames in the document, these will be ignored. Instead, you have to loop through all the StoryRanges, and search the content of each. Here's what I do in VB.NET to search the main text story and text frames:
Private Sub FindReplaceAll(ByVal objDoc As Object, ByVal strFind As String, ByVal strReplacement As String)
Dim rngStory As Object
For Each rngStory In objDoc.StoryRanges
Do
If rngStory.StoryType = wdMainTextStory Or rngStory.StoryType = wdTextFrameStory Then
With rngStory.Find
.Text = strFind
.Replacement.Text = strReplacement
.Wrap = wdFindContinue
.Execute(Replace:=wdReplaceAll)
End With
End If
rngStory = rngStory.NextStoryRange
Loop Until rngStory Is Nothing
Next rngStory
End Sub
StoryRanges Collection Object
http://msdn.microsoft.com/en-us/library/bb178940%28office.12%29.aspx
I have a long history regarding document generation and mail merge. In the old days we were using Office COM extensively even in server side (ASP) applications. In years we have learnt that this approach was causing many problems and today I’m always advocating against using Office COM (Word automation) in almost any scenario.
With the Microsoft’s introduction of Open XML SDK we managed to create a solid mail-merge component that was many times faster and much more robust than the solution(s) with Office COM. In my experience Open XML SDK allows a developer to create a solid solution, but it takes a lot of effort and time to make it useful and robust.
There are several good document generation/processing libraries on the market. We later ended up purchasing one and in my opinion creating your own solution (based on Open XML SDK or Office COM) simply never pays off.
Currently we are using Docentric Toolkit which is a general purpose document processing library and even better template-based/mail-merge toolkit for .NET. It allows template design in MS Word and then populating them with application data and producing final documents in different formats.
You can look into using XSL to generate some WordML.
This technique is definitely convoluted but gives you a lot power in your layout.
You don't need any 3rd party controls to create a Word document. From 2007 and onward Word can read html as a word document. You simply save any web page with the ".doc" extension and Word will sort it out.
Simply create your web page with whatever formatting you want then save it with a .doc extension.
I used HttpWebRequestto call the Url (with parmaters) to my page then used WebResponse and Stream to get my page into a buffer, then StreamReader and StreamWriter to save it to an actual document. I've then got my own custom function to download the file.
If anyone wants my code let me know
So I have our MVC web application up and running and we'd like to introduce printing into the solution. We have an interface (using SharePoint Service 3.0) that displays many files (all Word files) for a particular product. What we'd like to have happen is for the user to checkbox all the files they want to print, select a printer, and go at it.
The checkbox implementation is easy, I'm trying to think of a good print solution (if there is any). I'm looking for "out of the box" type solutions. One thing I was thinking about was creating a web service on SharePoint that takes all the files selected, merges them (somehow), and temporarily posts one big doc that, when finished, the client will print, and then the document gets purged. Not exactly the fastest operation but seems like it could work.
What's your thoughts on an implementation?
What kind of Doc Files do you have?
Are they already in the DocX format?
If so you can merge them quite easy with the documentAPI
We have an application that makes heavy use of the RDS.Dataspace.
As in :
set objDS = CreateObject("RDS.DataSpace")
set objJB = objDS.CreateObject("JBdbio.dbio","http://<%=Request.ServerVariables("SERVER_NAME")%>")
To instantiate and then:
NewQry 2,"QryUpdtItem" ' To set the name of the stored procedure
AddParam 255,"ISBN",200,txtISBN.value 'params
AddParam 255,"Titl",200,Title.value
m = objJB.UpdateQry(arrPrm) 'do the call to execute the stored procedure
Some do updates, some selects, etc
With RDS now obsolete for a number of years. How can I keep my asp code and have a Dataspace to attach to my business object (JBDBIO).
Essentially we just pass all of our params and stored procedure to this business object and then just dish up the results.
And if I were to move this to .net - how could I do the same without ajaxing it -- this is all vbscript code that runs, in effect an application within IE
Its time for a complete redesign. VBScript in IE is just not something that you want to be taking forward.
If you still want to use the browser as a means of delivering an inhouse UI then consider ASP.NET-MVC. If you want to attempt to make the UI smooth in the browser then inclusion of AJAX is the direction you need to take.
OTH in your case it may be worth you considering the delivery of the UI in a non-browser medium. For example a Silverlight3 using Ria services may be a way forward, XBAP or Click-once installs may also be an option.
No matter what choice you make its going to be a steep learning curve to move away from ancient RDS/VBScript in the client. You may as well take the opportunity to re-visit the UI behaviour as well.
You said it "flickers" on postbacks in the page your guy had rewritten to ASP.NET, didn't the old version "flicker" on postback (submit)? And wow did the .NET code look like if you have not already found any .NET replacement for the database code?
Or have I not understood right, is the VBScript you are talking about client side VBScript? In that case you can actually use the old client side VBScript in the .NET page as well (just as you can run JavaScript on the client side).
If this does not point in any direction to a sollution, I think you might have to provide some more details with code examples, and what you want to acheive.