|
First, break out the GetPixel call into it's own line so you can see the value in the debugger:
Dim pixelColor As Color = img.GetPixel(x,y)
If pixelColor = color.Black Then
...
Step through the code line-by-line and look at the value of pixelColor Chances are good that the "black" you're seeing in the image is not really Color.Black, but close to it. Are you using a scanned or video image or was this text.bmp drawn in MSPaint or something else?
|
|
|
|
|
Hi frnds, Is there any codings to filter the data from the Excel Sheet using Visual Basic?
I need codings pls send it as soon as possible..
|
|
|
|
|
|
Hi.
I'm not sure whether or not this thread should go here or over in the API section, except that it involves declarations that are definitely vb.Net.
Anyway, my questions revolve around the use of IntPtr. My first thought was that since I needed to pass pointers to win32 functions, I needed to restrict myself to 32bit values. Therefore, it seems that IntPtr is only applicable when on a 32bit system. If a pointer is declared as IntPtr on a 64bit system, vb.Net is clever enough to make IntPtr fit the 64bitwidth of the current system. That makes it unusable for win32 functions because they can only deal with 32bit values. So then I thought, well, I'll switch to using UInt32, so that the API is accessible with a 32bit pointer. But then I thought, hm, that would be fine as far as the API function is concerned, but would create a problem when an API function returns a 32bit encoded address to a memory location on a 64bit system! So that seems to suggest that when you get the pointer out of the function, that it needs to be widened to a 64bit pointer so that the data there can be properly found and retrieved. So my questions are:
1. Is this logic basically correct?
2. Is IntPtr really nothing more than UInt32 or UInt64,
depending on the bitwidth of the system?
3. Again, if all of this is correct, is casting or
marshaling required to narrow and widen the pointer
when a conversion is necessary?
modified 8-Jun-13 23:14pm.
|
|
|
|
|
The IntPtr type will be 32 or 64 bits wide, as necessary, based on the target platform specified in the compiler options.
Use the best guess
|
|
|
|
|
Then if the target system is 64bit, conversion of data types will be necessary between that and the 32bit pointers required by win32, if I understand things correctly. So I can use UInt32 for a passed argument to the API and widen that on output from the API to UInt64. Which would require marshaling, correct?
|
|
|
|
|
No, just use IntPtr and the compiler will set it correctly for you.
Use the best guess
|
|
|
|
|
No, I already understand that part. The problem is that win32 API functions canNOT switch automatically...They're stuck in 32bit land. So it seems that conversion IS necessary when on a 64bit system right?
Also, just realized this morning, that for some API functions, it needs to be Int32 not UInt32, since some functions return an address of -1 on failure. Theoretically, it is the only negative number that would be returned, so this SHOULD be OK.
This whole thing bothers me though, because it means that any pointer that can be passed to a win32 function is stuck in the 32bit range of values. Although it would OK to widen this to 64bits after output from the function, by placing zeroes in the higher order 32 bits, it does not guarantee that a "low" 32bit address is even available. The only reason that might not be a problem is that a 32bit number is still awfully large and how many 32bit valid addresses ranges (blocks of memory) can you expect to be using during any Windows session, even with multitasking?
But on the other hand, is the bit order correct in an Int32 to be used directly as a pointer on a 64bit system, without having to convert to Int64? I am having return value problems in my functions and if I can put the addressing thing to rest, then I can move on to other culprits.
modified 9-Jun-13 15:24pm.
|
|
|
|
|
treddie wrote: They're stuck in 32bit land.
No, they are rebuilt for 64 bit, which is why the IntPtr type is provided.
Use the best guess
|
|
|
|
|
Ahh, OK. Then my theory is poop.  I will have to invent a new theory about something else, then!
Thanks for the clarification!
|
|
|
|
|
Hello,
I have an app that utilises web browser object to open a (local) html file enter pass that runs javascript within the html(nothing to do with me) that opens/ decrypts another HTML page with links to the encrypted files.. ..
All works fine for 1 or 2 files but I have 200+ that I have to convert. Without fail and at unfortunately but not on a particular file the app crashes and returns StackHash Error... I have added the exe to DEP Exceptions list. Rebooted and the error still returns.
How can i find out what is causing this error?
Hope somebody can help on this.
The crash occurs at the same piece of code. which is:
Sub HTTPDownloadFile(ByVal URL As String, ByVal LocalFileName As String)
Dim http As New Inet
Dim Contents() As Byte
On Error GoTo HTTPDownloadFile_Error
WriteLog "LInk" & URL
WriteLog "Path to save" & LocalFileName
10 ' Set http = New Inet
20 'Set http = CreateObject("InetCtls.Inet")
30 With http
40 .protocol = icHTTP
50 .URL = URL
60 Contents() = .OpenURL(.URL, icByteArray)
70 End With
80 ' Set http = Nothing
90 Open LocalFileName For Binary Access Write As #1
100 Put #1, , Contents()
110 Close #1
120 Set http = Nothing
WriteLog LocalFileName & "Saved"
On Error GoTo 0
Exit Sub
More specifically between the open and close statements.
Has anybody any suggestion as to what may cause this or how to avoid? this is my first step into vb so am cluelss about various compilation options.. would/ could any of thoese options help?
FYI am running on windows 7.
Thanks in advance.
|
|
|
|
|
champagne_charly wrote: More specifically between the open and close statements.
.NET throws Exceptions, not errors; looks like VB6-code. How about you try VB.NET?
There could be more than one download at a time, but each filehandle must be unique. See the FreeFile[^] function to get a handle, as opposed to hardcoding al to #1.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Thanks.. Yes it is vb6.. Can't remember where the .net error was mention however it was in an infobox at somepoint..
I will change all ref I have to include this update. I had completely forgotten the use of freefile. My gut Is (and I hope) this is the issue although only ever one file download is triggered at a time.
Will post back.
|
|
|
|
|
champagne_charly wrote: Yes it is vb6..
That's no longer supported. You can download VB.NET for free, which is supported.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
|
champagne_charly wrote: Supported by whom?
Microsoft. Meaning no updates for vulnerabilities, no guarantees to run after the next Automatic Windows Update. There might still be a large community, but the compiler is no longer sold nor maintained. That means that the part of the community that doesn't "move", will simply stay in the past, next to the C64-emulator.
champagne_charly wrote: Visual Basic 6 Renewed to Run on Windows 8
No, it's not. VB6 isn't being changed. Yes, it "might" run old VB6-applications, but that's where the good news ends. It doesn't mean that all those third-party COM controls will still be updated, nor that you'll be able to get support when things go wrong.
As for the article;
Karl E. Peterson added Agreed, a multi-threaded x64 VB7 would be a market slayer! […] They could sell it for the _next_ 20 years.
They did. It's called VB.NET.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Fair point re support... however VBA is still in use.. Will that ever die or be as much as a thing of the past as the c64? As far as I can see the VB6 and VBA are identitcal. The same code appears more stable compiled in vb6 than it was in outlook or access.
Controls used are same as in VBA. Else going forward interopt.
Funny you say that with regards VBfred:VB given VB.Net, "unlike other versions of VB, does not use the language syntax and behavior of MS Basis ". SO is vb.net really the VB7?
All that said I should make the jump... however ms access allows me to do what I need and in this case I just wanted some code running in backround hence why vb6.
I seem to -after many hours -have fixed the issue by replacing the function to not use binary but FSO MSStream and MSXML2 (at least I hope 270 decrypted and associated files downloaded).. although for some reason I keep loosing the focus on whatever I am working on.. Bet I'll get to that once it completes without error..
|
|
|
|
|
champagne_charly wrote: Controls used are same as in VBA. Else going forward interopt
Yeah? Go try and find new controls. Nobody is putting out new control packs for VB6/VBA.
Yeah, VBA is still around, but it'll never see 64-bit code support.
champagne_charly wrote: SO is vb.net really the VB7?
Yes it is. VB7 was .NET 1.x. Nearly everything VB6 worked. But, like everything else, VB.NET evolved and keeps evolving to support new technologies and capabilities, such a free-threading, Parallel Task Library, structured error handling, full OOP support, ... just to name a few.
VBA and VB6 are dead and stuck in the past. Good luck with it!
|
|
|
|
|
Ohh you again.. Why do you bother? Oh yeah of such experience and superior knowledge and all you can do is skitt? Tiring.
It was clear that i was working in vb6.. So why do you waste what must be such valuable time making silly remarks..
FYI there are new controls still being written that are vba compatible.. i shall excuse what is clearly your ignorance to the same. And why shoudlnt you be ignorant when you know such superior things!..
To put it politely, you've been as much help as a chocolate teapot and proving yourself to be rather irritating along with.
Good day to you sir!
|
|
|
|
|
Hehehe!
Have a nice life!
|
|
|
|
|
champagne_charly wrote: Fair point re support... however VBA is still in use.
So is VB6, despite people like me actively trying to kill it. It's a catastrophic success that simply refuses to die.
champagne_charly wrote: Will that ever die or be as much as a thing of the past as the c64?
It's not that black and white; it's being phased out and replaced by .NET versions. VBA is meant as an in-application script host, even though they can be run stand-alone. And yes, in ten years time you'll still come across a customer with some XP-machine that hasn't seen an update since it was installed. (These are often the cozy homes of botnets)
champagne_charly wrote: As far as I can see the VB6 and VBA are identitcal.
Close! VBA and VB6 share syntax and some libraries. There was a third taste, called "eVB" (embedded), used to write in VB6-style for WinCE 5.
champagne_charly wrote: All that said I should make the jump... however ms access allows me to do what I need
Most of the corporate users do not need anything beyond C64-basic to do their work. Move to a modern platform, or be obsoleted - that's the choice.
I'm not saying that it's easy to make a move; I'm a WinForm-programmer, and even though WinForms isn't obsoleted yet, and despite the fact that it'll only generate costs and bugs to replace a working form, I know I can't stay hooked on the forms forever. It's often a good idea to use the old and tested way, so one can guarantee a result - but for that we depend on the manufacturer of the OS to support our infrastructure.
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Hi,
You mentioned the very point which was the cause of my hesitation of moving away from access.. "WinForms isn't obsoleted yet" But it will be so then what? Which direction.. ugghhh.. Not being a programmer by trade I havent got time to do and then do again hence why I go for the simplicity of MSA and MSSSQL. Knowing the MSSQL will be applicable no matter what and its just front end interface that is the issue. Maybe next little standalone script I write I will attempt (again) at ?.Net..
Anyway thanks for the comments and interesting v valid points.
Regards
|
|
|
|
|
champagne_charly wrote: "WinForms isn't obsoleted yet" But it will be so then what?
Then I'll be obsoleted too. I don't expect MS to kill WinForms, but I do see a complete market moving away from it.
champagne_charly wrote: Not being a programmer by trade I havent got time to do and then do again hence why I go for the simplicity of MSA and MSSSQL.
It's not that big a move; VB.NET looks a lot like VB6, and MSSQL will still behave the same. But yes, it's a matter of weighing pro's and con's. Imagine investing heavily in the outdated stuff - what would it cost to get it "current" again? Look at the activity and "support" for Delphi. We got a Delphi-forum, but it's not as active as it would have been in the days of Delphi 5.
champagne_charly wrote: Knowing the MSSQL will be applicable no matter what
SQL92 is applicable, no matter what - MSSQL is tied to a vendor.
champagne_charly wrote: its just front end interface that is the issue.
Which has to be easy, intuitive and cheap. At least, in my view. It's one of the things I enjoy in .NET; one can generate a UI based on the table being fetched. Ever used a PropertyGrid? It's great if you want to edit an object, without spending much time on the UI.
FWIW, generating a UI can be speed up in a multitude of ways, with CodeSmith[^] as one of the older generators. I'd recommend MyGeneration[^] though.
Alternatively, you might consider handing the coding to a beginner and focus on managing and designing the application. If you feel that above ideas take too much time, than your project might have outgrown the current phase and might benefit from some extra hands and eyes.
champagne_charly wrote: Anyway thanks for the comments
My pleasure; my apologies for being rude against VB6
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Lol.. MS to kill WinForms is Of course way off.. I wanted the most portable type interface (Linux + MS) so was at the time contemplating java/ silverlight but of the same token playing with c#.. just ignorance really.. But didnt get very far other than getting myself wound up by not havign clear direction.
Ok.. so VS express now installed for the next step.
Sure I read the delphi issues was this not to do with the delay in release of decent x64 architecture? Or maybe that was just specific to what I had been looking into at the time  ..
Sure property grids but unless simple I'd rather write the code to the same. However I say that without knowing the complexities of the same within .net.
YOung developers..mmm.. with no doubt all with better knowledge than I however... yes i did a few times but frequently the wrong ones and as a result I spent more time chasing debugging and repeating myself oh and puling my hair out (to the point of having little left) in dispair than much else. Hence why my thoughts are design structure in a simple way (access + decent x64 compatible components ) that is then useable (for current business) then the architecture in terms of structure is in place. THus the rest can be a modular upgrade apporach.
I didn't read any rudeness from you more of a valid arguments.
Regards
P.S> initial issue completely rectified.
|
|
|
|
|
champagne_charly wrote: I wanted the most portable type interface (Linux + MS) so was at the time contemplating java/ silverlight
I'm targetting the same platforms, but using WinForms. The .NET assemblies are binary compatible, meaning I can compile on Windows using VS, and use them under OpenSUSE/Ubuntu without modification. Then again, using a webinterface would allow even more clients to use the application - even the Kindle can display a webpage.
champagne_charly wrote: I read the delphi issues was this not to do with the delay in release of decent x64 architecture?
We abandoned the IDE before the move to 64-bit code; people don't mind being in 32-bits that much, see VB6 as proof. A lot of applications are still bound to the 32-bit platform due to the bitness of the libraries they reference. The amount of users dropped significantly when "Borland" (or whatever name they had at that moment) discontinued the free version.
champagne_charly wrote: Sure property grids but unless simple I'd rather write the code to the same. However I say that without knowing the complexities of the same within .net.
Since you're already familiar with VB6, it could be as simple as asking which properties a record has, and creating a huge "switch" to display an editor for that property. The new framework will add more useful goodies to your toolbox, like real threading.
champagne_charly wrote: THus the rest can be a modular upgrade apporach.
That's the ideal architecture; anything that can be described in terms of input/output can easily be tested and outsourced/offloaded to someone else. Otherwise one will always have problems with integrating the different parts and getting them to work together.
champagne_charly wrote: P.S> initial issue completely rectified.
Hehe, guilty, it's sometimes hard to stay on topic 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
