|
I am looking for documentation on how to do the following. I want to see some examples on how to print to a template document. For example an invoice. I assume I need to specify the xy coordinates. But, I can't find or don't know what to put in to search engine to get documentation on this.
Can someone please help me?
Thank you.
|
|
|
|
|
It's rendered the same way you do things in a forn or control's paint event. You have to render strings of text and graphics in certain locations the just happen to be where the fields are on the page.
Settying this up is quite a time consuming, trial-and-error process, so be prepared to go through a lot of paper.
On the other hand, you might want to consider using a forms library, like Adobe Acrobat to layout you fields, then have your code fill them in using Acrobat Reaer. When that's done, you can have Acrobat Reader print the finished form.
|
|
|
|
|
If your data for the invoice is in a windows form (textboxes and labels etc.) then the Form Print Control[^] can turn this into a printed page style document and allows you to control the x,y, font, colour and so on of the generated output.
|
|
|
|
|
hi,
how can i communicate with a bluetooth gps in vb.net?
i've an usb bluetooth and i would recive from gps nmea string latitude and longitude.
how can i do this in vb.net and visual studio 2005/08?
|
|
|
|
|
|
Dumb question, but what's the best and easiest way to persist all of the form sizes (and perhaps other information, such as datagridview column layouts) across sessions?
Thanks
|
|
|
|
|
Write your own serializer to save all this information when the app/form closes and reload it, setting all the appropriate properties, the next time the app/form is created.
|
|
|
|
|
You might want to look at the My.Settings[^] stuff. There are several articles around, like this one.[^]. Probably not the best, but maybe easier than others.
|
|
|
|
|
Ditto. Very easy to do with the app settings if your looking for a quick and easy way to do it.
Any suggestions, ideas, or 'constructive criticism' are always welcome.
|
|
|
|
|
I know, I know - my article.[^]
How could this possibly be a dumb question!
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Thank you... very helpful. To followup on your point, I always liked this quote, supposedly from Frank Zappa.
Some scientists claim that hydrogen, because it is so plentiful, is the basic building block of the universe. I dispute that. I say there is more stupidity than hydrogen, and that is the basic building block of the universe.
|
|
|
|
|
How can I populate database from binding Navigator using button boxes not the controls
|
|
|
|
|
What do you mean by "populate"? Are you asking how to navigate between records?? Your question is a little confusing.
|
|
|
|
|
Please rephrase your question, it is not clear enough 
"The clue train passed his station without stopping." - John Simmons / outlaw programmer
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
"Not only do you continue to babble nonsense, you can't even correctly remember the nonsense you babbled just minutes ago." - Rob Graham
|
|
|
|
|
Navigator is just that for navigating the table, it has no functionality to CRUD the data.
Whats a "button box"
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Hello,
I have got to do a lot of request with a database.
I would like to know if it is more efficient to use a permanent connection or to create a new connection each time i have to got to make a request ?
Will i lose a lot of performance by using the second system
Thanks
|
|
|
|
|
It depends on several things, like number of users, are you using connection pooling etc etc. It used to be standard practice to keep connections open, but mostly these days (assuming connection pooling is being used) then connections are opened and closed as required. The best bet is to run a eries of benchmarks as its easy enough to implement both methods.
Bob
Ashfield Consultants Ltd
|
|
|
|
|
Depending on the DBMS you are using, the number of concurrent connections may be limited.
|
|
|
|
|
Best practice depends on how often your going to the database to retrieve stuff and the number of users you have.
Connections to SQL Servers are expensive, money wise that is, so hanging onto a connection for the life of your apps runtime can be VERY expensive. If you did this, say you have 10 users who run your app. If all 10 run at the same time, you need 10 connection licenses on your SQL Server, multiplied by the cost of your connection licenses.
Now, if you use best practice, and only open a connection for as long as you need to retrieve a block of data or do an update, then you can get away with using fewer connection licenses. An application spends 95%+ of its life idle, not doing anything with the database. So, that same 10 users running your app could share, say 1 to 3 connection licenses. It just become much cheaper to run your application.
What you do depends on your applications requirements. You need to find a happy balance between these two and the performance benefits you gain, from your own testing of course.
|
|
|
|
|
Use a Data Access Layer (DAL) to manage your connection to the DB and service the data requirements for your app.
Use pooling in your connection
Create a standard sql credential for your app (userid/password) and not integrated.
We close a connection after each operation, this puts the connection into the pool for approx 8 minutes before killing the connection.
Use data adaptor.fill instead of data reader.
The above are recommendations only, we use them in our corporate apps.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: Use data adaptor.fill instead of data reader.
Why?
Do you realise that the DataAdapter.Fill method uses a DataReader, so you can't really use the DataAdapter.Fill method without using a DataReader?
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Guffa wrote: Do you realise that the DataAdapter.Fill method uses a DataReader
Sure but a datareader locks the connection while the reader is active ie if you process on the reader say to fill a combo box then the connection is locked during the processing. Data adaptor releases the connection as soon as you complete the read, any subsequent processing is on a disconnected data adapter. Adaptor costs more but I never have a locked connection.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Mycroft Holmes wrote: Sure but a datareader locks the connection while the reader is active ie if you process on the reader say to fill a combo box then the connection is locked during the processing.
Of course you should read the data from the DataReader into some data structure, and then work on the data once you closed the connection. The data structure doesn't have to be a bloated DataTable object, though.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
I was trying to have a newbie avoid the trap of locking a connection with a reader, it certainly happenned to me and it was a painful experience chasing down the problem in MSDN. It was long before I had discovered Google.
And that is why I put the recommendation comment on the reply.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
What are you telling me this?? Tell the OP!
I know all this. I just addressed the very narrow question he asked. "Is it better to open a connection for the life of an app?"
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
