|
The same way you did with the exe.
I'll leave this one up to you
Ericos Georgiades
|
|
|
|
|
okai ..let me try and get back to u ..
Thanks again...
|
|
|
|
|
Hi,
I know there is probably a simple answer to this.
I've created a deployment project and I cannot get the Readme.rtf file to display. I added it to the APPLICATION FOLDER, then to the USER INTERFACE with the "readmefile" property set to the file. When I run the install nothing shows. Anyone have any ideas?
Thanks
zxcvbnm
|
|
|
|
|
Hi,
I see that I'm not the only one facing that problem, at first i thought it was a bug, until, I came across a few other guys facing the same issue. I'm also looking for a work around to this problem, and would be glad if someone knew what the problem is
|
|
|
|
|
Hi! everybody.
How can I get the name of SQL Servers on my network. When I load main form, I want to get SQL servers name into combobox and the user can choose which server they want to use. Could you help me please.
Thanks in advance.
|
|
|
|
|
Ok, you can set a bitmap transparency by saying something along these lines:
Bitmap.MakeTransparent(Color)
but after you have done this, is there a way to either
1.) retrieve this color so you know what the transparent color is
2.) remove transparency for this color and set a different color for transparency
Help on either question would be MUCH apreciated.
Thanks
Pablo
Sometimes I think there's no reason to get out of bed . . . then I feel wet, and I realize there is.
|
|
|
|
|
Is it possible to add buttons to list view at runtime in vb?
|
|
|
|
|
Yes, but you would have to draw them manually.
Trinity: Neo... nobody has ever done this before.
Neo: That's why it's going to work.
|
|
|
|
|
I need to add buttons as list items. Can u tell me how to do that
|
|
|
|
|
Okay, so I want to use Embeded resources in two ways in VB.NET 2005 Express:
1) ToolBoxBitmap on User Control
2) To load images from at runtime.
I have searched and racked my brain, and am really starting to not want to finish this project.
Thanks,
Tibmeister
|
|
|
|
|
I am looking for a simple routine to print what is on the screen to a printer based on a button being pressed.
Thanks
silver-gray
|
|
|
|
|
I've written a calculation-intensive application under VBA for Excel. The program is non-trivial and quite large. It is currently being used for complicated financial calculations. The problem is that it is very slow. I have gone through the code and made many tweaks to increase the speed (reduced array re-dimensions, eliminated redundant and/or repetitive function calls, etc...) and the speed gains do not improve things "enough" for my liking. Thus, I have decided to re-write the program, a non-trivial exercise.
Now, I am a c++ programmer so ideally I would re-write this in Visual C++ or something, but someone has suggested importing it into Visual Basic. My question is: will this be any faster? I am not sure if VBA is basically interpreted rather than compiled and thus slower than, say, a compiled Visual Basic app. Is this indeed the case, or will I be wasting time importing the VBA code to Visual Basic? If so, then the solution appears to be C++ despite the headache of interfacing VC++ with Excel. Any advice would be appreciated.
"Oh, I must've did somebody some good. I think I did. So I gave her the gun and I shot her!" - Led Zeppelin - In My Time of Dying
|
|
|
|
|
The Apocalyptic Teacup wrote: I am not sure if VBA is basically interpreted rather than compiled and thus slower than, say, a compiled Visual Basic app.
VBA is interpreted according to wiki, VBA wiki[^]
I am sure porting to C++ would be worthwhile
|
|
|
|
|
PaulC1972 wrote: I am sure porting to C++ would be worth
I agree. However, there seems to be a large problem. I'm trying to drive Excel 2000 through C#, but I'm encountering some problems with Primary Interop Assemblies...I think I need Excel 2003 or even more recent...
"Oh, I must've did somebody some good. I think I did. So I gave her the gun and I shot her!" - Led Zeppelin - In My Time of Dying
|
|
|
|
|
The Apocalyptic Teacup wrote:
My thoughts exactly
|
|
|
|
|
PaulC1972 wrote: My thoughts exactly
Yeah. I guess I convince my employer that the simulation runs for 12 hours while I get a day off! Oh, if only...
"Oh, I must've did somebody some good. I think I did. So I gave her the gun and I shot her!" - Led Zeppelin - In My Time of Dying
|
|
|
|
|
The Apocalyptic Teacup wrote: the simulation runs for 12 hours
Sounds like it could use some optimizing then.
|
|
|
|
|
PaulC1972 wrote: Sounds like it could use some optimizing then.
Indeed - hence this thread!
"Oh, I must've did somebody some good. I think I did. So I gave her the gun and I shot her!" - Led Zeppelin - In My Time of Dying
|
|
|
|
|
Did you run an analysis, identify the procedures that are consuming the most time, and optimize them? This would be the first step before making a decision to rewrite in another language.
How large is the program? Converting to VB.Net might be the most prudent and quickest.
|
|
|
|
|
arcticbrew wrote: Did you run an analysis, identify the procedures that are consuming the most time, and optimize them? This would be the first step before making a decision to rewrite in another language.
No, but I have a pretty good idea where the slow code is. I execute a number of loops and the number of calculations can reach a maximum of 15000 iterations of a particular function. As it stands right now, it is taking approximately 12 hours to complete a simulation and that is, honestly, unacceptable. I really need to trim this down.
arcticbrew wrote: How large is the program? Converting to VB.Net might be the most prudent and quickest.
The program is about 5000 lines. So it's not exactly trivial to port it to C# or C++, for example. It also interfaces extensively with Excel 2000 (uses the charting functions as well as some spreadsheet entries), but on a first investigation, there seems to be a problem driving Excel 2000 with C#...something about Primary Interop Assemblies...Oh dear.
"Oh, I must've did somebody some good. I think I did. So I gave her the gun and I shot her!" - Led Zeppelin - In My Time of Dying
|
|
|
|
|
1. Within Excel, ensure that the calculation mode is set to 'Manual' and not automatic.
2. VBA is interpreted; anything compiled should be faster.
3. If the application is already written in VBA in Excel, porting it to VB should be a breeze... essentially cut and paste.
Good, bad, or otherwise, I work in the VBA/Excel environment just about every day.
Tim
|
|
|
|
|
Hi Tim, thanks for the response.
Tim Carmichael wrote: 1. Within Excel, ensure that the calculation mode is set to 'Manual' and not automatic.
Yes, have already done this.
Tim Carmichael wrote: 2. VBA is interpreted; anything compiled should be faster.
That's what I was thinking. But two issues. The first is: How much faster? The second is that I read that VBA is basically interfaced with Excel from a DLL and thus should have really low overhead. I am therefore suspicious as to whether or not porting it to VB is really going to improve the situation noticeably...
Tim Carmichael wrote: 3. If the application is already written in VBA in Excel, porting it to VB should be a breeze... essentially cut and paste.
Yes, but it uses the charting functionality of Excel extensively. I was trying to do a preliminary investigation as to whether or not I could write this in C#, but there seems to be an issue with the Primary Interop Assemblies between C# and Excel 2000. From what I have read, it would seem that I need Excel 2003 or even Office XP to get around this. I don't know if there is a solution for Excel 2000. Gah, what a mess!
"Oh, I must've did somebody some good. I think I did. So I gave her the gun and I shot her!" - Led Zeppelin - In My Time of Dying
|
|
|
|
|
I feel your pain...
If you need to use the charting functions in Excel, it it possible to offload the processing into a DLL?
I have some user-written Excel spreadsheets (again, for charting) that use a great deal of data... as much as possible, I have modified the VBA code to offload processing to a DLL or a stored procedure. The only interaction with Excel then is: get the data, put the data, chart the data...
If I can help, let me know.
Tim
|
|
|
|
|
Tim Carmichael wrote: I feel your pain...
Tim Carmichael wrote: If you need to use the charting functions in Excel, it it possible to offload the processing into a DLL?
I'm not exactly sure what you mean. Are you suggesting I write the calculation/simulation code in Visual Basic and compile it to a DLL and then call the DLL from VBA in excel? Or is it the other way around? Package the Excel charting capability into a DLL and call that from my VB app?
"Oh, I must've did somebody some good. I think I did. So I gave her the gun and I shot her!" - Led Zeppelin - In My Time of Dying
|
|
|
|
|
Well... from my end, the charting was done directly in Excel with VBA calling DLLs written in VB to do the bulk of the work.
I have had opportunity to write code that opens Excel spreadsheets... but that caused other issues and was difficult to debug what was happening in Excel.
But... either way works.
|
|
|
|