|
Thanks for the info i think the breakpoint issue should be related to the threading problem as well.. btw tis is my code.. i didnt use any thread but dun know y i encounter the problem..
Private Delegate Sub SerialPort1_DataReceivedDelegate(ByVal sender As System.Object)
Private Sub SerialPort1_DataReceived(ByVal sender As System.Object, ByVal e As System.IO.Ports.SerialDataReceivedEventArgs) Handles port.DataReceived
If port.BytesToRead > 0 Then
CheckForIllegalCrossThreadCalls = False
Dim bytetoread As Integer
bytetoread = port.BytesToRead
Dim byteArray(bytetoread) As Byte
Dim lineData As String
port.Read(byteArray, 0, bytetoread)
lineData = ConvertToString(byteArray)
TxtCommand.Text = lineData
End If
End Sub
Private Function ConvertToString(ByVal byteArray As Byte()) As String
Dim tempStringToReturn As String = ""
For Each bt As Byte In byteArray
tempStringToReturn = tempStringToReturn + Convert.ToChar(bt)
Next
Return tempStringToReturn
End Function
modified on Wednesday, February 25, 2009 10:46 PM
|
|
|
|
|
No Clue !! , it does not seem that any threading is used in the code you pasted , i am really not able to think of any other cause of problem 
-Regards
Bharat Jain
bharat.jain.nagpur@gmail.com
|
|
|
|
|
Sorry for bothering you with stupid sounding stuff from me newbie...
During my first tries with VB 2008 Express I'm creating an application which calls a command line tool for image processing (in loops). From their support I received the hint "With so many images to process, performance will be dramatically improved if you can use a scripting language like PerlMagick, RMagick, TclMagick, or a compiled language like C/C++."
I had thought that VB 2008 Express IS a compiled language. Is that wrong? Coming from VBA and VB Script I have some background with the VB syntax etc, that's why I chose to enhance that to VB 2008 rather than beginning with C for my simple (private) purposes.
Thanks for bringing some light to my darkness 
|
|
|
|
|
VB.Net compiles to MSIL (Microsoft Intermediate Language), and then you deploy that file (.exe) to your clients. Your clients must have the .NET Framework which includes the JIT (Just In Time) Compiler. The JIT then interprets your MSIL and executes the commands.
In short, it compiles, but not to native code such as C++/C. It compiles to MSIL. There are downsides to this, and upsides to this. Obviously, one of the bigger advantages is the fear of garbage collecting is gone when using a managed language, also the gigantic framework at your fingertips allowing you to develop applications at a great speed with (hopefully) little ease difficulty lol.
Hope that helps.
|
|
|
|
|
EliottA wrote: The JIT then interprets your MSIL and executes the commands.
No, it doesn't. The JIT compiles the MSIL code down to processor-specific native machine code.
So, yes, VB.NET is a compiled language, just like C# or C++, ...
|
|
|
|
|
Hey Dave,
after having written my other answer I just read yours and my live makes sense again  God bless you!
To be more serious: At least I humbly realized the big gap between a professional programmers (necessary?) approach and my limited skills - which are still good enough for enjoying it, and also for many programming tasks as long as I don't set myself too ambitious goals.
Sincerely
Michael
|
|
|
|
|
This reply is completely wrong.
The intermediate language is compiled into executable code at run-time, it is not interpreted and executed line by line. One of the main benefits of JIT compiling is that the compiler can optimize the resulting machine code to take advantage of the features of the CPU and operating system installed in the end-user's machine.
|
|
|
|
|
Little further clarification on what's been posted already for those not familiar with the topic.
MSIL is compiled to native (machine) code at runtime to take advantage of varying CPUs and architecture types; however the JIT compiler does not compile the entire assembly at once - it is done at a method by method level. It is possible to pre-compile using NGEN.
When a method is called, that method then gets compiled to native code (once per the lifetime of the assembly). If there are methods that are never called during the operation of the assembly, then they never get converted to native code. This is done to increase performance during startup and runtime of the assembly to avoid a massive hit during initial startup.
Any suggestions, ideas, or 'constructive criticism' are always welcome.
"There's no such thing as a stupid question, only stupid people." - Mr. Garrison
|
|
|
|
|
|
Thank you both... although after reading the article I have to admit that the issue yet seems to be completely beyond my understanding  .
Guess I'm better off living with the performance issue in the particular case - coz if I dive deeper into that kind of issues  I might have to give up my day job and my family.
Have a nice evening and thanks still!
|
|
|
|
|
If you're worried about the speed, you could use ngen[^] which compiles your application to processor specific code.
|
|
|
|
|
Partially true. It doesn't speed up your code though. All NGEN does is precompile everything all at once instead of waiting for the JIT to do the same thing on-the-fly.
|
|
|
|
|
Hi,
VB.NET is a compiled language, it is capable of offering adequate performance for normal jobs.
Other languages, even interpreted ones, could be capable of the same as long as they have native
libraries for the most challenging tasks. On the other hand a mediocre programmer will always be able to create a dog that performs terribly, whatever language he chooses.
Luc Pattyn [Forum Guidelines] [My Articles]
- before you ask a question here, search CodeProject, then Google
- the quality and detail of your question reflects on the effectiveness of the help you are likely to get
- use the code block button (PRE tags) to preserve formatting when showing multi-line code snippets
|
|
|
|
|
Basically I have multiple Excel files and each file has four sheets. I am trying to print each work book to a separate PDF. The first work books converts to a PDF with no problem however on the second go-around PDFCreator hangs and only the last page of the second work book is saved as a PDF. I've been working on this nonstop for two days now and can't figure out what else to do. Below is the code (with comments) for the sub routine that is supposed to do the conversion. The lines between asterisks is where the code hangs. Thanks in advance. PS: Sorry for the long code.
With m_ExcelApp 'This is the Excel COM object
.Visible = False 'Ensure that all work is done in the background
pdfjob = New PDFCreator.clsPDFCreator 'The PDFCreator object is created
' If pdfjob.cStart("/NoProcessingAtStartup") = False Then
MsgBox("Can't initialize PDFCreator.", MsgBoxStyle.Critical + MsgBoxStyle.OkOnly, "Error!")
Exit Sub
End If
'/// This is opening up the Excel file one by one ///
For i As Integer = 0 To IntDistList.Count - 1
PSFileName = IntDistList(i).ToString.Insert(IntDistList(i).ToString.LastIndexOf("\"), "\Reports") & ".pdf"
workbook = .Workbooks.Open(IntDistList(i).ToString.Insert(IntDistList(i).ToString.LastIndexOf("\"), "\Reports") & ".xml")
sheet = .ActiveWorkbook.Sheets(2)
sheet.Activate()
sheet.PageSetup.PrintTitleRows = "$1:$9"
sheet = .ActiveWorkbook.Sheets(3)
sheet.Activate()
sheet.PageSetup.PrintTitleRows = "$1:$10"
.ActiveWorkbook.Save()
' div = PSFileName.Split("\")
sPDFName = div(div.GetUpperBound(0))
sPDFPath = PSFileName.Substring(0, PSFileName.LastIndexOf("\")) & "\"
'/// Set all default settings ///
With pdfjob
.cOption("UseAutoSave") = 1
.cOption("UseAutosaveDirectory") = 1
.cOption("AutosaveDirectory") = sPDFPath
.cOption("AutosaveFilename") = sPDFName
.cOption("AutosaveFormat") = 0 ' 0 = PDF
.cClearCache()
End With
'/// Print the file to PDF ///
lTtlSheets = .Sheets.Count
For lSheet = 1 To .Sheets.Count
If .Sheets(lSheet).usedrange IsNot Nothing Then
.Sheets(lSheet).printout(activeprinter:="PDFCreator")
Else
lTtlSheets -= 1
End If
Next
'/// Wait until all print job have entered the print queue ///
'*******************This is where the program hangs on the second go-around but works fine for the first file*****************
Do Until pdfjob.cCountOfPrintjobs = lTtlSheets
Thread.Sleep(30)
Loop
'************************************************
'/// Combine all PDFs into a single file and stop the printer ///
ChangeStatus("Combining Files")
With pdfjob
.cCombineAll()
.cPrinterStop = False
End With
'/// Wait until PDF creator is finished then release the objects ///
ChangeStatus("Finalizing File")
Do Until pdfjob.cCountOfPrintjobs = 0
Thread.Sleep(1000)
Loop
Thread.Sleep(2500)
ChangeStatus("Closing File")
.ActiveWorkbook.Close()
PSFileMerge.Add(PSFileName)
Next
ChangeStatus("Releasing Objects")
pdfjob.cClose()
pdfjob = Nothing
End With
|
|
|
|
|
|
I know...I know. I originally had this working perfectly with Adobe Acrobat but after I finished it that's when my company decided that they didn't want to get Acrobat for everyone so I'm trying to figure out a way around it using free PDF printers. If you know other way that'll work I would love to know since this is my last obstacle. I really can't wait till Adobe comes out with there finally PDF-XML standard and I can just go to that.
|
|
|
|
|
I really don't, but I feel your pain. We (at this company) are making an ESRP where excel is the engine, I've been designated the VBA guy. I've not opened VS in 3 months, sometimes I open it just to hope.
|
|
|
|
|
I think I would have an easier time if I was actually doing all of the work in Excel, but I'm using Interop because there is a bunch of pre & post processing I have to do on the data and files.
|
|
|
|
|
I finally figured it out. The line .cPrinterStop = False starts the printer drives to output the final PDF. What was happening is that unless you stop it again it will only output the last sheet. So after all the processing is done on one workbook you need to add .cPrinterStop = True so the printer will not output anything until all the intermediate PDFs are processed and and the printer is restarted by the .cPrinterStop = False on the next loop. Wish there had been better IntelliSense on this matter but it works now. What a headache.
|
|
|
|
|
Hello frnds,
Here is the issue.
My application should check whether or not the space provided for displaying a string (in different languages) is sufficient. I have Width and Height of the space provided in pixels and font type, font size of the string.
So how can i solve this? I can think of 2 ways.
1. Get width of each character and sum up to get the width needed in pixels. For this i need to know width of each character in pixels? Is there a way i can find this?
2. There should be a predefined API to get the width of the string in pixels. If yes what is that API?
Any help would be highly appreciated.
Thanks,
Hari krishna.
|
|
|
|
|
Not sure if this will work for you, but have you tried using MeasureString? You can try something like this:
Dim g As Graphics
Dim size As New SizeF
Dim myFont As New Font("Arial",8) 'Just as an example, you can replace it with whatever font/size you are using
g=CreateGraphics()
size=g.MeasureString(myString,myFont)
g.Dispose
Don't forget to import System.Drawing.Graphics
Dominick
|
|
|
|
|
Dominick,
Thanks for the prompt response. Is there a way i can acheive this in VB?
Thanks,
Hari krishna.
|
|
|
|
|
That was VB, VB.Net... what are you working with if not VB.net?
|
|
|
|
|
The example I gave was VB.NET
|
|
|
|
|
Ok, I'm confused because the example presented to you earlier was in VB.Net, code done and everything. All you had to do was just tweak it a bit to suit your needs. But you didn't... you asked him how to use it...
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
